From tamizhr at codeaurora.org  Sat Jul  4 11:13:30 2020
From: tamizhr at codeaurora.org (Tamizh Chelvam)
Date: Sat,  4 Jul 2020 20:43:30 +0530
Subject: [PATCHv2 0/4] ath10k: Add support for TID specific configuration
Message-ID: <1593875614-5683-1-git-send-email-tamizhr@codeaurora.org>

Add TID specific configuration for noack, retry count, aggregation, Tx rate
and RTS_CTS control. Here if noack is enabled for the TID then aggregation
should be disabled and Tx rate should be and retry count will be 0.
Also add support for reset TID configuration.


Tamizh Chelvam (4):
  ath10k: Add wmi command support for station specific TID config
  ath10k: Move rate mask validation function up in the file
  ath10k: Add new api to support TID specific configuration
  ath10k: Add new api to support reset TID config

v2:

 * Fixed warnings reported by kernel test robot <lkp at intel.com>

 drivers/net/wireless/ath/ath10k/core.c    |   4 +
 drivers/net/wireless/ath/ath10k/core.h    |  20 +
 drivers/net/wireless/ath/ath10k/mac.c     | 837 ++++++++++++++++++++++++++----
 drivers/net/wireless/ath/ath10k/txrx.c    |  11 +-
 drivers/net/wireless/ath/ath10k/wmi-ops.h |  19 +
 drivers/net/wireless/ath/ath10k/wmi.c     |  35 ++
 drivers/net/wireless/ath/ath10k/wmi.h     |  72 +++
 7 files changed, 905 insertions(+), 93 deletions(-)

-- 
1.9.1



From tamizhr at codeaurora.org  Sat Jul  4 11:13:31 2020
From: tamizhr at codeaurora.org (Tamizh Chelvam)
Date: Sat,  4 Jul 2020 20:43:31 +0530
Subject: [PATCHv2 1/4] ath10k: Add wmi command support for station specific
 TID config
In-Reply-To: <1593875614-5683-1-git-send-email-tamizhr@codeaurora.org>
References: <1593875614-5683-1-git-send-email-tamizhr@codeaurora.org>
Message-ID: <1593875614-5683-2-git-send-email-tamizhr@codeaurora.org>

This patch adds WMI interface to configure station specific
TID configuration . Host needs to send station's MAC address
along with TID number and its configuration to target through
WMI_10_4_PER_PEER_PER_TID_CONFIG_CMDID.

WMI_SERVICE_PEER_TID_CONFIGS_SUPPORT flag is added to advertise
this support.

Tested-on: QCA9984 hw1.0 PCI 10.4-3.9.0.2-00021

Signed-off-by: Tamizh Chelvam <tamizhr at codeaurora.org>
---
 drivers/net/wireless/ath/ath10k/wmi-ops.h | 19 +++++++++++
 drivers/net/wireless/ath/ath10k/wmi.c     | 32 +++++++++++++++++++
 drivers/net/wireless/ath/ath10k/wmi.h     | 52 +++++++++++++++++++++++++++++++
 3 files changed, 103 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/wmi-ops.h b/drivers/net/wireless/ath/ath10k/wmi-ops.h
index 0dd484f..fc9e3ae 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-ops.h
+++ b/drivers/net/wireless/ath/ath10k/wmi-ops.h
@@ -224,6 +224,8 @@ struct wmi_ops {
 	struct sk_buff *(*gen_bb_timing)
 			(struct ath10k *ar,
 			 const struct wmi_bb_timing_cfg_arg *arg);
+	struct sk_buff *(*gen_per_peer_per_tid_cfg)(struct ath10k *ar,
+				const struct wmi_per_peer_per_tid_cfg_arg *arg);
 
 };
 
@@ -1656,4 +1658,21 @@ struct wmi_ops {
 	return ath10k_wmi_cmd_send(ar, skb,
 				   ar->wmi.cmd->set_bb_timing_cmdid);
 }
+
+static inline int
+ath10k_wmi_set_per_peer_per_tid_cfg(struct ath10k *ar,
+				const struct wmi_per_peer_per_tid_cfg_arg *arg)
+{
+	struct sk_buff *skb;
+
+	if (!ar->wmi.ops->gen_per_peer_per_tid_cfg)
+		return -EOPNOTSUPP;
+
+	skb = ar->wmi.ops->gen_per_peer_per_tid_cfg(ar, arg);
+	if (IS_ERR(skb))
+		return PTR_ERR(skb);
+
+	return ath10k_wmi_cmd_send(ar, skb,
+				   ar->wmi.cmd->per_peer_per_tid_config_cmdid);
+}
 #endif
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index a81a1ab..4316551 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -740,6 +740,7 @@
 	.tdls_peer_update_cmdid = WMI_10_4_TDLS_PEER_UPDATE_CMDID,
 	.tdls_set_offchan_mode_cmdid = WMI_10_4_TDLS_SET_OFFCHAN_MODE_CMDID,
 	.radar_found_cmdid = WMI_10_4_RADAR_FOUND_CMDID,
+	.per_peer_per_tid_config_cmdid = WMI_10_4_PER_PEER_PER_TID_CONFIG_CMDID,
 };
 
 static struct wmi_peer_param_map wmi_peer_param_map = {
@@ -9005,6 +9006,36 @@ static u32 ath10k_wmi_prepare_peer_qos(u8 uapsd_queues, u8 sp)
 }
 
 static struct sk_buff *
+ath10k_wmi_10_4_gen_per_peer_per_tid_cfg(struct ath10k *ar,
+				const struct wmi_per_peer_per_tid_cfg_arg *arg)
+{
+	struct wmi_peer_per_tid_cfg_cmd *cmd;
+	struct sk_buff *skb;
+
+	skb = ath10k_wmi_alloc_skb(ar, sizeof(*cmd));
+	if (!skb)
+		return ERR_PTR(-ENOMEM);
+
+	memset(skb->data, 0, sizeof(*cmd));
+
+	cmd = (struct wmi_peer_per_tid_cfg_cmd *)skb->data;
+	cmd->vdev_id = cpu_to_le32(arg->vdev_id);
+	ether_addr_copy(cmd->peer_macaddr.addr, arg->peer_macaddr.addr);
+	cmd->tid = cpu_to_le32(arg->tid);
+	cmd->ack_policy = cpu_to_le32(arg->ack_policy);
+	cmd->aggr_control = cpu_to_le32(arg->aggr_control);
+	cmd->rate_control = cpu_to_le32(arg->rate_ctrl);
+	cmd->retry_count = cpu_to_le32(arg->retry_count);
+	cmd->rcode_flags = cpu_to_le32(arg->rcode_flags);
+
+	ath10k_dbg(ar, ATH10K_DBG_WMI,
+		   "wmi noack tid %d vdev id %d ack_policy %d aggr %u rate_ctrl %u rcflag %u retry_count %d mac_addr %pM\n",
+		   arg->tid, arg->vdev_id, arg->ack_policy, arg->aggr_control, arg->rate_ctrl,
+		   arg->rcode_flags, arg->retry_count, arg->peer_macaddr.addr);
+	return skb;
+}
+
+static struct sk_buff *
 ath10k_wmi_op_gen_echo(struct ath10k *ar, u32 value)
 {
 	struct wmi_echo_cmd *cmd;
@@ -9413,6 +9444,7 @@ static u32 ath10k_wmi_prepare_peer_qos(u8 uapsd_queues, u8 sp)
 	.gen_pdev_get_tpc_table_cmdid =
 			ath10k_wmi_10_4_op_gen_pdev_get_tpc_table_cmdid,
 	.gen_radar_found = ath10k_wmi_10_4_gen_radar_found,
+	.gen_per_peer_per_tid_cfg = ath10k_wmi_10_4_gen_per_peer_per_tid_cfg,
 
 	/* shared with 10.2 */
 	.pull_echo_ev = ath10k_wmi_op_pull_echo_ev,
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index 511144b..7fed735 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -203,6 +203,7 @@ enum wmi_service {
 	WMI_SERVICE_SYNC_DELETE_CMDS,
 	WMI_SERVICE_TX_PWR_PER_PEER,
 	WMI_SERVICE_SUPPORT_EXTEND_ADDRESS,
+	WMI_SERVICE_PEER_TID_CONFIGS_SUPPORT,
 
 	/* Remember to add the new value to wmi_service_name()! */
 
@@ -503,6 +504,7 @@ static inline char *wmi_service_name(enum wmi_service service_id)
 	SVCSTR(WMI_SERVICE_SYNC_DELETE_CMDS);
 	SVCSTR(WMI_SERVICE_TX_PWR_PER_PEER);
 	SVCSTR(WMI_SERVICE_SUPPORT_EXTEND_ADDRESS);
+	SVCSTR(WMI_SERVICE_PEER_TID_CONFIGS_SUPPORT);
 
 	case WMI_SERVICE_MAX:
 		return NULL;
@@ -834,6 +836,8 @@ static inline void wmi_10_4_svc_map(const __le32 *in, unsigned long *out,
 	       WMI_SERVICE_TX_PWR_PER_PEER, len);
 	SVCMAP(WMI_10_4_SERVICE_RESET_CHIP,
 	       WMI_SERVICE_RESET_CHIP, len);
+	SVCMAP(WMI_10_4_SERVICE_PEER_TID_CONFIGS_SUPPORT,
+	       WMI_SERVICE_PEER_TID_CONFIGS_SUPPORT, len);
 }
 
 #undef SVCMAP
@@ -1036,6 +1040,7 @@ struct wmi_cmd_map {
 	u32 tdls_set_offchan_mode_cmdid;
 	u32 radar_found_cmdid;
 	u32 set_bb_timing_cmdid;
+	u32 per_peer_per_tid_config_cmdid;
 };
 
 /*
@@ -1877,6 +1882,8 @@ enum wmi_10_4_cmd_id {
 	WMI_10_4_PDEV_SET_BRIDGE_MACADDR_CMDID,
 	WMI_10_4_ATF_GROUP_WMM_AC_CONFIG_REQUEST_CMDID,
 	WMI_10_4_RADAR_FOUND_CMDID,
+	WMI_10_4_PEER_CFR_CAPTURE_CMDID,
+	WMI_10_4_PER_PEER_PER_TID_CONFIG_CMDID,
 	WMI_10_4_PDEV_UTF_CMDID = WMI_10_4_END_CMDID - 1,
 };
 
@@ -7220,6 +7227,51 @@ struct wmi_tdls_peer_event {
 	__le32 vdev_id;
 } __packed;
 
+enum wmi_tid_aggr_control_conf {
+	WMI_TID_CONFIG_AGGR_CONTROL_IGNORE,
+	WMI_TID_CONFIG_AGGR_CONTROL_ENABLE,
+	WMI_TID_CONFIG_AGGR_CONTROL_DISABLE,
+};
+
+enum wmi_noack_tid_conf {
+	WMI_NOACK_TID_CONFIG_IGNORE_ACK_POLICY,
+	WMI_PEER_TID_CONFIG_ACK,
+	WMI_PEER_TID_CONFIG_NOACK,
+};
+
+enum wmi_tid_rate_ctrl_conf {
+	WMI_TID_CONFIG_RATE_CONTROL_IGNORE,
+	WMI_TID_CONFIG_RATE_CONTROL_AUTO,
+	WMI_TID_CONFIG_RATE_CONTROL_FIXED_RATE,
+	WMI_TID_CONFIG_RATE_CONTROL_DEFAULT_LOWEST_RATE,
+};
+
+struct wmi_per_peer_per_tid_cfg_arg {
+	u32 vdev_id;
+	struct wmi_mac_addr peer_macaddr;
+	u32 tid;
+	enum wmi_noack_tid_conf ack_policy;
+	enum wmi_tid_aggr_control_conf aggr_control;
+	u8 rate_ctrl;
+	u32 retry_count;
+	u32 rcode_flags;
+};
+
+struct wmi_peer_per_tid_cfg_cmd {
+	__le32 vdev_id;
+	struct wmi_mac_addr peer_macaddr;
+	__le32 tid;
+
+	/* see enum wmi_noack_tid_conf */
+	__le32 ack_policy;
+	/* see enum wmi_tid_aggr_control_conf */
+	__le32 aggr_control;
+	/* see enum wmi_tid_rate_ctrl_conf */
+	__le32 rate_control;
+	__le32 rcode_flags;
+	__le32 retry_count;
+} __packed;
+
 enum wmi_txbf_conf {
 	WMI_TXBF_CONF_UNSUPPORTED,
 	WMI_TXBF_CONF_BEFORE_ASSOC,
-- 
1.9.1



From tamizhr at codeaurora.org  Sat Jul  4 11:13:32 2020
From: tamizhr at codeaurora.org (Tamizh Chelvam)
Date: Sat,  4 Jul 2020 20:43:32 +0530
Subject: [PATCHv2 2/4] ath10k: Move rate mask validation function up in the
 file
In-Reply-To: <1593875614-5683-1-git-send-email-tamizhr@codeaurora.org>
References: <1593875614-5683-1-git-send-email-tamizhr@codeaurora.org>
Message-ID: <1593875614-5683-3-git-send-email-tamizhr@codeaurora.org>

This patch does not have any functional changes.

Tested-on: QCA9984 hw1.0 PCI 10.4-3.9.0.2-00021

Signed-off-by: Tamizh Chelvam <tamizhr at codeaurora.org>
---
 drivers/net/wireless/ath/ath10k/mac.c | 174 +++++++++++++++++-----------------
 1 file changed, 87 insertions(+), 87 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 3e38962..7023ccf 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -6602,6 +6602,93 @@ static int ath10k_sta_set_txpwr(struct ieee80211_hw *hw,
 	return ret;
 }
 
+static bool
+ath10k_mac_bitrate_mask_has_single_rate(struct ath10k *ar,
+					enum nl80211_band band,
+					const struct cfg80211_bitrate_mask *mask,
+					int *vht_num_rates)
+{
+	int num_rates = 0;
+	int i, tmp;
+
+	num_rates += hweight32(mask->control[band].legacy);
+
+	for (i = 0; i < ARRAY_SIZE(mask->control[band].ht_mcs); i++)
+		num_rates += hweight8(mask->control[band].ht_mcs[i]);
+
+	*vht_num_rates = 0;
+	for (i = 0; i < ARRAY_SIZE(mask->control[band].vht_mcs); i++) {
+		tmp = hweight16(mask->control[band].vht_mcs[i]);
+		num_rates += tmp;
+		*vht_num_rates += tmp;
+	}
+
+	return num_rates == 1;
+}
+
+static int
+ath10k_mac_bitrate_mask_get_single_rate(struct ath10k *ar,
+					enum nl80211_band band,
+					const struct cfg80211_bitrate_mask *mask,
+					u8 *rate, u8 *nss, bool vht_only)
+{
+	int rate_idx;
+	int i;
+	u16 bitrate;
+	u8 preamble;
+	u8 hw_rate;
+
+	if (vht_only)
+		goto next;
+
+	if (hweight32(mask->control[band].legacy) == 1) {
+		rate_idx = ffs(mask->control[band].legacy) - 1;
+
+		if (ar->phy_capability & WHAL_WLAN_11A_CAPABILITY)
+			rate_idx += ATH10K_MAC_FIRST_OFDM_RATE_IDX;
+
+		hw_rate = ath10k_wmi_legacy_rates[rate_idx].hw_value;
+		bitrate = ath10k_wmi_legacy_rates[rate_idx].bitrate;
+
+		if (ath10k_mac_bitrate_is_cck(bitrate))
+			preamble = WMI_RATE_PREAMBLE_CCK;
+		else
+			preamble = WMI_RATE_PREAMBLE_OFDM;
+
+		*nss = 1;
+		*rate = preamble << 6 |
+			(*nss - 1) << 4 |
+			hw_rate << 0;
+
+		return 0;
+	}
+
+	for (i = 0; i < ARRAY_SIZE(mask->control[band].ht_mcs); i++) {
+		if (hweight8(mask->control[band].ht_mcs[i]) == 1) {
+			*nss = i + 1;
+			*rate = WMI_RATE_PREAMBLE_HT << 6 |
+				(*nss - 1) << 4 |
+				(ffs(mask->control[band].ht_mcs[i]) - 1);
+
+			return 0;
+		}
+	}
+
+next:
+	for (i = 0; i < ARRAY_SIZE(mask->control[band].vht_mcs); i++) {
+		if (hweight16(mask->control[band].vht_mcs[i]) == 1) {
+			*nss = i + 1;
+			*rate = WMI_RATE_PREAMBLE_VHT << 6 |
+				(*nss - 1) << 4 |
+				(ffs(mask->control[band].vht_mcs[i]) - 1);
+
+			return 0;
+		}
+	}
+
+	return -EINVAL;
+}
+
 static int ath10k_sta_state(struct ieee80211_hw *hw,
 			    struct ieee80211_vif *vif,
 			    struct ieee80211_sta *sta,
@@ -7352,30 +7439,6 @@ static int ath10k_get_survey(struct ieee80211_hw *hw, int idx,
 }
 
 static bool
-ath10k_mac_bitrate_mask_has_single_rate(struct ath10k *ar,
-					enum nl80211_band band,
-					const struct cfg80211_bitrate_mask *mask,
-					int *vht_num_rates)
-{
-	int num_rates = 0;
-	int i, tmp;
-
-	num_rates += hweight32(mask->control[band].legacy);
-
-	for (i = 0; i < ARRAY_SIZE(mask->control[band].ht_mcs); i++)
-		num_rates += hweight8(mask->control[band].ht_mcs[i]);
-
-	*vht_num_rates = 0;
-	for (i = 0; i < ARRAY_SIZE(mask->control[band].vht_mcs); i++) {
-		tmp = hweight16(mask->control[band].vht_mcs[i]);
-		num_rates += tmp;
-		*vht_num_rates += tmp;
-	}
-
-	return num_rates == 1;
-}
-
-static bool
 ath10k_mac_bitrate_mask_get_single_nss(struct ath10k *ar,
 				       enum nl80211_band band,
 				       const struct cfg80211_bitrate_mask *mask,
@@ -7424,69 +7487,6 @@ static int ath10k_get_survey(struct ieee80211_hw *hw, int idx,
 	return true;
 }
 
-static int
-ath10k_mac_bitrate_mask_get_single_rate(struct ath10k *ar,
-					enum nl80211_band band,
-					const struct cfg80211_bitrate_mask *mask,
-					u8 *rate, u8 *nss, bool vht_only)
-{
-	int rate_idx;
-	int i;
-	u16 bitrate;
-	u8 preamble;
-	u8 hw_rate;
-
-	if (vht_only)
-		goto next;
-
-	if (hweight32(mask->control[band].legacy) == 1) {
-		rate_idx = ffs(mask->control[band].legacy) - 1;
-
-		if (ar->phy_capability & WHAL_WLAN_11A_CAPABILITY)
-			rate_idx += ATH10K_MAC_FIRST_OFDM_RATE_IDX;
-
-		hw_rate = ath10k_wmi_legacy_rates[rate_idx].hw_value;
-		bitrate = ath10k_wmi_legacy_rates[rate_idx].bitrate;
-
-		if (ath10k_mac_bitrate_is_cck(bitrate))
-			preamble = WMI_RATE_PREAMBLE_CCK;
-		else
-			preamble = WMI_RATE_PREAMBLE_OFDM;
-
-		*nss = 1;
-		*rate = preamble << 6 |
-			(*nss - 1) << 4 |
-			hw_rate << 0;
-
-		return 0;
-	}
-
-	for (i = 0; i < ARRAY_SIZE(mask->control[band].ht_mcs); i++) {
-		if (hweight8(mask->control[band].ht_mcs[i]) == 1) {
-			*nss = i + 1;
-			*rate = WMI_RATE_PREAMBLE_HT << 6 |
-				(*nss - 1) << 4 |
-				(ffs(mask->control[band].ht_mcs[i]) - 1);
-
-			return 0;
-		}
-	}
-
-next:
-	for (i = 0; i < ARRAY_SIZE(mask->control[band].vht_mcs); i++) {
-		if (hweight16(mask->control[band].vht_mcs[i]) == 1) {
-			*nss = i + 1;
-			*rate = WMI_RATE_PREAMBLE_VHT << 6 |
-				(*nss - 1) << 4 |
-				(ffs(mask->control[band].vht_mcs[i]) - 1);
-
-			return 0;
-		}
-	}
-
-	return -EINVAL;
-}
-
 static int ath10k_mac_set_fixed_rate_params(struct ath10k_vif *arvif,
 					    u8 rate, u8 nss, u8 sgi, u8 ldpc)
 {
-- 
1.9.1



From tamizhr at codeaurora.org  Sat Jul  4 11:13:34 2020
From: tamizhr at codeaurora.org (Tamizh Chelvam)
Date: Sat,  4 Jul 2020 20:43:34 +0530
Subject: [PATCHv2 4/4] ath10k: Add new api to support reset TID config
In-Reply-To: <1593875614-5683-1-git-send-email-tamizhr@codeaurora.org>
References: <1593875614-5683-1-git-send-email-tamizhr@codeaurora.org>
Message-ID: <1593875614-5683-5-git-send-email-tamizhr@codeaurora.org>

Add ops for reset_tid_config to support reset TID
configuration. This send default configuration to the
target for the TIDs and stores default value in the host.

Tested-on: QCA9984 hw1.0 PCI 10.4-3.9.0.2-00021

Signed-off-by: Tamizh Chelvam <tamizhr at codeaurora.org>
---
 drivers/net/wireless/ath/ath10k/core.h |  1 +
 drivers/net/wireless/ath/ath10k/mac.c  | 88 ++++++++++++++++++++++++++++++++++
 2 files changed, 89 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 939cf01..4cf5bd4 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -633,6 +633,7 @@ struct ath10k_vif {
 	u8 rate_ctrl[ATH10K_TID_MAX];
 	u32 rate_code[ATH10K_TID_MAX];
 	int rtscts[ATH10K_TID_MAX];
+	u32 tids_rst;
 };
 
 struct ath10k_vif_iter {
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 991f274..594e7af 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -6689,6 +6689,7 @@ static int ath10k_sta_set_txpwr(struct ieee80211_hw *hw,
 struct ath10k_mac_iter_tid_conf_data {
 	struct ieee80211_vif *curr_vif;
 	struct ath10k *ar;
+	bool reset_config;
 };
 
 static bool
@@ -7071,6 +7072,54 @@ static int ath10k_mac_set_tid_config(struct ath10k *ar, struct ieee80211_sta *st
 	return ret;
 }
 
+static int ath10k_mac_reset_tid_config(struct ath10k *ar,
+				       struct ieee80211_sta *sta,
+				       struct ath10k_vif *arvif,
+				       u8 tids)
+{
+	struct ath10k_sta *arsta = (struct ath10k_sta *)sta->drv_priv;
+	struct wmi_per_peer_per_tid_cfg_arg arg;
+	int ret = 0, i = 0;
+
+	arg.vdev_id = arvif->vdev_id;
+	while (i < ATH10K_TID_MAX) {
+		if (!(tids & BIT(i))) {
+			i++;
+			continue;
+		}
+
+		arg.tid = i;
+		arg.ack_policy = WMI_PEER_TID_CONFIG_ACK;
+		arg.retry_count = ATH10K_MAX_RETRY_COUNT;
+		arg.rate_ctrl = WMI_TID_CONFIG_RATE_CONTROL_AUTO;
+		arg.aggr_control = WMI_TID_CONFIG_AGGR_CONTROL_ENABLE;
+		arg.rtscts_ctrl = WMI_TID_CONFIG_RTSCTS_CONTROL_ENABLE;
+		arg.ext_tid_cfg_bitmap = WMI_EXT_TID_RTS_CTS_CONFIG;
+		ether_addr_copy(arg.peer_macaddr.addr, sta->addr);
+		ret = ath10k_wmi_set_per_peer_per_tid_cfg(ar, &arg);
+		if (ret)
+			return ret;
+
+		if (!arvif->tids_rst) {
+			arsta->retry_long[i] = -1;
+			arsta->noack[i] = -1;
+			arsta->ampdu[i] = -1;
+			arsta->rate_code[i] = -1;
+			arsta->rate_ctrl[i] = 0;
+			arsta->rtscts[i] = -1;
+		} else {
+			arvif->retry_long[i] = 0;
+			arvif->noack[i] = 0;
+			arvif->ampdu[i] = 0;
+			arvif->rate_code[i] = 0;
+			arvif->rate_ctrl[i] = 0;
+			arvif->rtscts[i] = 0;
+		}
+		i++;
+	}
+	return ret;
+}
+
 static void ath10k_sta_tid_cfg_wk(struct work_struct *wk)
 {
 	struct wmi_per_peer_per_tid_cfg_arg arg = {};
@@ -7089,6 +7138,12 @@ static void ath10k_sta_tid_cfg_wk(struct work_struct *wk)
 
 	mutex_lock(&ar->conf_mutex);
 
+	if (arvif->tids_rst) {
+		ret = ath10k_mac_reset_tid_config(ar, sta, arvif,
+						  arvif->tids_rst);
+		goto exit;
+	}
+
 	ether_addr_copy(arg.peer_macaddr.addr, sta->addr);
 	for (i = 0; i < ATH10K_TID_MAX; i++) {
 		config_apply = false;
@@ -7177,6 +7232,7 @@ static void ath10k_sta_tid_cfg_wk(struct work_struct *wk)
 		arg.rcode_flags = 0;
 	}
 
+exit:
 	mutex_unlock(&ar->conf_mutex);
 }
 
@@ -9078,6 +9134,7 @@ static int ath10k_mac_op_set_tid_config(struct ieee80211_hw *hw,
 	mutex_lock(&ar->conf_mutex);
 	arg.vdev_id = arvif->vdev_id;
 
+	arvif->tids_rst = 0;
 	memset(arvif->tid_conf_changed, 0, sizeof(arvif->tid_conf_changed));
 
 	for (i = 0; i < tid_config->n_tid_conf; i++) {
@@ -9092,6 +9149,7 @@ static int ath10k_mac_op_set_tid_config(struct ieee80211_hw *hw,
 		goto exit;
 
 	ret = 0;
+	arvif->tids_rst = 0;
 	data.curr_vif = vif;
 	data.ar = ar;
 
@@ -9103,6 +9161,35 @@ static int ath10k_mac_op_set_tid_config(struct ieee80211_hw *hw,
 	return ret;
 }
 
+static int ath10k_mac_op_reset_tid_config(struct ieee80211_hw *hw,
+					  struct ieee80211_vif *vif,
+					  struct ieee80211_sta *sta,
+					  u8 tids)
+{
+	struct ath10k_vif *arvif = (void *)vif->drv_priv;
+	struct ath10k_mac_iter_tid_conf_data data = {};
+	struct ath10k *ar = hw->priv;
+	int ret = 0;
+
+	mutex_lock(&ar->conf_mutex);
+
+	if (sta) {
+		arvif->tids_rst = 0;
+		ret = ath10k_mac_reset_tid_config(ar, sta, arvif, tids);
+		goto exit;
+	}
+
+	arvif->tids_rst = tids;
+	data.curr_vif = vif;
+	data.ar = ar;
+	ieee80211_iterate_stations_atomic(hw, ath10k_mac_vif_stations_tid_conf,
+					  &data);
+
+exit:
+	mutex_unlock(&ar->conf_mutex);
+	return ret;
+}
+
 static const struct ieee80211_ops ath10k_ops = {
 	.tx				= ath10k_mac_op_tx,
 	.wake_tx_queue			= ath10k_mac_op_wake_tx_queue,
@@ -9147,6 +9234,7 @@ static int ath10k_mac_op_set_tid_config(struct ieee80211_hw *hw,
 	.sta_pre_rcu_remove		= ath10k_mac_op_sta_pre_rcu_remove,
 	.sta_statistics			= ath10k_sta_statistics,
 	.set_tid_config			= ath10k_mac_op_set_tid_config,
+	.reset_tid_config		= ath10k_mac_op_reset_tid_config,
 
 	CFG80211_TESTMODE_CMD(ath10k_tm_cmd)
 
-- 
1.9.1



From tamizhr at codeaurora.org  Sat Jul  4 11:13:33 2020
From: tamizhr at codeaurora.org (Tamizh Chelvam)
Date: Sat,  4 Jul 2020 20:43:33 +0530
Subject: [PATCHv2 3/4] ath10k: Add new api to support TID specific
 configuration
In-Reply-To: <1593875614-5683-1-git-send-email-tamizhr@codeaurora.org>
References: <1593875614-5683-1-git-send-email-tamizhr@codeaurora.org>
Message-ID: <1593875614-5683-4-git-send-email-tamizhr@codeaurora.org>

This patch add ops for set_tid_config to support TID
specific configuration. Station specific TID configuration
will have more priority than vif specific TID configuration.
WMI_SERVICE_PEER_TID_CONFIGS_SUPPORT service flag introduced
to notify host for TID config support. And RTS_CTS extended tid
configuration support advertised through the service flag
WMI_10_4_SERVICE_EXT_PEER_TID_CONFIGS_SUPPORT.

TID specific noack configuration requires
aggregation should be disabled and rate for the data TID packets
should be basic rates. So, if the TID already configured
with noack policy then driver will ignore the aggregation
or TX rate related configuration for the same data TID.

In TX rate configuration should be applied with highest
preamble configuration(HT rates should not be applied
for the station which supports vht rates).

Tested-on: QCA9984 hw1.0 PCI 10.4-3.9.0.2-00021

Signed-off-by: Tamizh Chelvam <tamizhr at codeaurora.org>
---
 drivers/net/wireless/ath/ath10k/core.c |   4 +
 drivers/net/wireless/ath/ath10k/core.h |  19 ++
 drivers/net/wireless/ath/ath10k/mac.c  | 575 ++++++++++++++++++++++++++++++++-
 drivers/net/wireless/ath/ath10k/txrx.c |  11 +-
 drivers/net/wireless/ath/ath10k/wmi.c  |   9 +-
 drivers/net/wireless/ath/ath10k/wmi.h  |  20 ++
 6 files changed, 629 insertions(+), 9 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 22b6937..18b7587 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -2797,6 +2797,10 @@ int ath10k_core_start(struct ath10k *ar, enum ath10k_firmware_mode mode,
 		if (test_bit(WMI_SERVICE_REPORT_AIRTIME, ar->wmi.svc_map))
 			val |= WMI_10_4_REPORT_AIRTIME;
 
+		if (test_bit(WMI_SERVICE_EXT_PEER_TID_CONFIGS_SUPPORT,
+			     ar->wmi.svc_map))
+			val |= WMI_10_4_EXT_PEER_TID_CONFIGS_SUPPORT;
+
 		status = ath10k_mac_ext_resource_config(ar, val);
 		if (status) {
 			ath10k_err(ar,
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 5c18f6c..939cf01 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -82,6 +82,8 @@
 /* Default Airtime weight multipler (Tuned for multiclient performance) */
 #define ATH10K_AIRTIME_WEIGHT_MULTIPLIER  4
 
+#define ATH10K_MAX_RETRY_COUNT 30
+
 struct ath10k;
 
 static inline const char *ath10k_bus_str(enum ath10k_bus bus)
@@ -109,6 +111,7 @@ enum ath10k_skb_flags {
 	ATH10K_SKB_F_MGMT = BIT(3),
 	ATH10K_SKB_F_QOS = BIT(4),
 	ATH10K_SKB_F_RAW_TX = BIT(5),
+	ATH10K_SKB_F_NOACK_TID = BIT(6),
 };
 
 struct ath10k_skb_cb {
@@ -509,6 +512,8 @@ struct ath10k_htt_tx_stats {
 	u64 ack_fails;
 };
 
+#define ATH10K_TID_MAX	8
+
 struct ath10k_sta {
 	struct ath10k_vif *arvif;
 
@@ -542,6 +547,13 @@ struct ath10k_sta {
 #endif
 	/* Protected with ar->data_lock */
 	u32 peer_ps_state;
+	struct work_struct tid_config_wk;
+	int noack[ATH10K_TID_MAX];
+	int retry_long[ATH10K_TID_MAX];
+	int ampdu[ATH10K_TID_MAX];
+	u8 rate_ctrl[ATH10K_TID_MAX];
+	u32 rate_code[ATH10K_TID_MAX];
+	int rtscts[ATH10K_TID_MAX];
 };
 
 #define ATH10K_VDEV_SETUP_TIMEOUT_HZ	(5 * HZ)
@@ -614,6 +626,13 @@ struct ath10k_vif {
 	/* For setting VHT peer fixed rate, protected by conf_mutex */
 	int vht_num_rates;
 	u8 vht_pfr;
+	u32 tid_conf_changed[ATH10K_TID_MAX];
+	int noack[ATH10K_TID_MAX];
+	int retry_long[ATH10K_TID_MAX];
+	int ampdu[ATH10K_TID_MAX];
+	u8 rate_ctrl[ATH10K_TID_MAX];
+	u32 rate_code[ATH10K_TID_MAX];
+	int rtscts[ATH10K_TID_MAX];
 };
 
 struct ath10k_vif_iter {
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 7023ccf..991f274 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3018,6 +3018,66 @@ static void ath10k_bss_disassoc(struct ieee80211_hw *hw,
 	cancel_delayed_work_sync(&arvif->connection_loss_work);
 }
 
+static int ath10k_new_peer_tid_config(struct ath10k *ar,
+				      struct ieee80211_sta *sta,
+				      struct ath10k_vif *arvif)
+{
+	struct wmi_per_peer_per_tid_cfg_arg arg = {};
+	struct ath10k_sta *arsta = (struct ath10k_sta *)sta->drv_priv;
+	bool config_apply;
+	int ret, i;
+
+	for (i = 0; i < ATH10K_TID_MAX; i++) {
+		config_apply = false;
+		if (arvif->retry_long[i] || arvif->ampdu[i] ||
+		    arvif->rate_ctrl[i] || arvif->rate_ctrl[i] ||
+		    arvif->rtscts[i]) {
+			config_apply = true;
+			arg.tid = i;
+			arg.vdev_id = arvif->vdev_id;
+			arg.retry_count = arvif->retry_long[i];
+			arg.aggr_control = arvif->ampdu[i];
+			arg.rate_ctrl = arvif->rate_ctrl[i];
+			arg.rcode_flags = arvif->rate_code[i];
+			if (arvif->rtscts[i])
+				arg.ext_tid_cfg_bitmap =
+					WMI_EXT_TID_RTS_CTS_CONFIG;
+			else
+				arg.ext_tid_cfg_bitmap = 0;
+			arg.rtscts_ctrl = arvif->rtscts[i];
+		}
+
+		if (arvif->noack[i]) {
+			arg.ack_policy	= arvif->noack[i];
+			arg.rate_ctrl =
+				WMI_TID_CONFIG_RATE_CONTROL_DEFAULT_LOWEST_RATE;
+			arg.aggr_control = WMI_TID_CONFIG_AGGR_CONTROL_DISABLE;
+			config_apply = true;
+		}
+
+		/* Assign default value(-1) to newly connected station.
+		 * This is to identify station specific tid configuration not
+		 * configured for the station.
+		 */
+		arsta->retry_long[i] = -1;
+		arsta->noack[i] = -1;
+		arsta->ampdu[i] = -1;
+
+		if (!config_apply)
+			continue;
+
+		ether_addr_copy(arg.peer_macaddr.addr, sta->addr);
+		ret = ath10k_wmi_set_per_peer_per_tid_cfg(ar, &arg);
+		if (ret) {
+			ath10k_warn(ar, "failed to set per tid retry/aggr config for sta %pM: %d\n",
+				    sta->addr, ret);
+			return ret;
+		}
+		memset(&arg, 0, sizeof(arg));
+	}
+	return 0;
+}
+
 static int ath10k_station_assoc(struct ath10k *ar,
 				struct ieee80211_vif *vif,
 				struct ieee80211_sta *sta,
@@ -3083,7 +3143,10 @@ static int ath10k_station_assoc(struct ath10k *ar,
 		}
 	}
 
-	return ret;
+	if (!test_bit(WMI_SERVICE_PEER_TID_CONFIGS_SUPPORT, ar->wmi.svc_map))
+		return ret;
+
+	return ath10k_new_peer_tid_config(ar, sta, arvif);
 }
 
 static int ath10k_station_disassoc(struct ath10k *ar,
@@ -3631,7 +3694,10 @@ static void ath10k_mac_tx_h_fill_cb(struct ath10k *ar,
 	const struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
 	bool is_data = ieee80211_is_data(hdr->frame_control) ||
 			ieee80211_is_data_qos(hdr->frame_control);
+	struct ath10k_vif *arvif = (void *)vif->drv_priv;
 	struct ath10k_sta *arsta;
+	u8 tid, *qos_ctl;
+	bool noack = false;
 
 	cb->flags = 0;
 	if (!ath10k_tx_h_use_hwcrypto(vif, skb))
@@ -3640,8 +3706,26 @@ static void ath10k_mac_tx_h_fill_cb(struct ath10k *ar,
 	if (ieee80211_is_mgmt(hdr->frame_control))
 		cb->flags |= ATH10K_SKB_F_MGMT;
 
-	if (ieee80211_is_data_qos(hdr->frame_control))
+	if (ieee80211_is_data_qos(hdr->frame_control)) {
 		cb->flags |= ATH10K_SKB_F_QOS;
+		qos_ctl = ieee80211_get_qos_ctl(hdr);
+		tid = (*qos_ctl) & IEEE80211_QOS_CTL_TID_MASK;
+
+		if (arvif->noack[tid] == WMI_PEER_TID_CONFIG_NOACK)
+			noack = true;
+
+		if (sta) {
+			arsta = (struct ath10k_sta *)sta->drv_priv;
+			if (arsta->noack[tid] == WMI_PEER_TID_CONFIG_NOACK)
+				noack = true;
+
+			if (arsta->noack[tid] == WMI_PEER_TID_CONFIG_ACK)
+				noack = false;
+		}
+
+		if (noack)
+			cb->flags |= ATH10K_SKB_F_NOACK_TID;
+	}
 
 	/* Data frames encrypted in software will be posted to firmware
 	 * with tx encap mode set to RAW. Ex: Multicast traffic generated
@@ -6602,6 +6686,11 @@ static int ath10k_sta_set_txpwr(struct ieee80211_hw *hw,
 	return ret;
 }
 
+struct ath10k_mac_iter_tid_conf_data {
+	struct ieee80211_vif *curr_vif;
+	struct ath10k *ar;
+};
+
 static bool
 ath10k_mac_bitrate_mask_has_single_rate(struct ath10k *ar,
 					enum nl80211_band band,
@@ -6689,6 +6778,421 @@ static int ath10k_sta_set_txpwr(struct ieee80211_hw *hw,
 	return -EINVAL;
 }
 
+static int ath10k_mac_validate_rate_mask(struct ath10k *ar,
+					 struct ieee80211_sta *sta,
+					 u32 rate_ctrl_flag, u8 nss)
+{
+	if (nss > sta->rx_nss) {
+		ath10k_warn(ar, "Invalid nss field, configured %u limit %u\n",
+			    nss, sta->rx_nss);
+		return -EINVAL;
+	}
+
+	if (ATH10K_HW_PREAMBLE(rate_ctrl_flag) == WMI_RATE_PREAMBLE_VHT) {
+		if (!sta->vht_cap.vht_supported) {
+			ath10k_warn(ar, "Invalid VHT rate for sta %pM\n",
+				    sta->addr);
+			return -EINVAL;
+		}
+	} else if (ATH10K_HW_PREAMBLE(rate_ctrl_flag) == WMI_RATE_PREAMBLE_HT) {
+		if (!sta->ht_cap.ht_supported || sta->vht_cap.vht_supported) {
+			ath10k_warn(ar, "Invalid HT rate for sta %pM\n",
+				    sta->addr);
+			return -EINVAL;
+		}
+	} else {
+		if (sta->ht_cap.ht_supported || sta->vht_cap.vht_supported) {
+			return -EINVAL;
+		}
+	}
+
+	return 0;
+}
+
+static int
+ath10k_mac_tid_bitrate_config(struct ath10k *ar,
+			      struct ieee80211_vif *vif,
+			      struct ieee80211_sta *sta,
+			      u32 *rate_ctrl_flag, u8 *rate_ctrl,
+			      enum nl80211_tx_rate_setting txrate_type,
+			      const struct cfg80211_bitrate_mask *mask)
+{
+	struct cfg80211_chan_def def;
+	enum nl80211_band band;
+	u8 nss, rate;
+	int vht_num_rates, ret;
+
+	if (WARN_ON(ath10k_mac_vif_chan(vif, &def)))
+		return -EINVAL;
+
+	if (txrate_type == NL80211_TX_RATE_AUTOMATIC) {
+		*rate_ctrl = WMI_TID_CONFIG_RATE_CONTROL_AUTO;
+		*rate_ctrl_flag = 0;
+		return 0;
+	}
+
+	band = def.chan->band;
+
+	if (!ath10k_mac_bitrate_mask_has_single_rate(ar, band, mask,
+						     &vht_num_rates)) {
+		return -EINVAL;
+	}
+
+	ret = ath10k_mac_bitrate_mask_get_single_rate(ar, band, mask,
+						      &rate, &nss, false);
+	if (ret) {
+		ath10k_warn(ar, "failed to get single rate: %d\n",
+			    ret);
+		return ret;
+	}
+	*rate_ctrl_flag = rate;
+
+	if (sta && ath10k_mac_validate_rate_mask(ar, sta, *rate_ctrl_flag, nss))
+		return -EINVAL;
+
+	if (txrate_type == NL80211_TX_RATE_FIXED)
+		*rate_ctrl = WMI_TID_CONFIG_RATE_CONTROL_FIXED_RATE;
+	else if (txrate_type == NL80211_TX_RATE_LIMITED &&
+		 (test_bit(WMI_SERVICE_EXT_PEER_TID_CONFIGS_SUPPORT,
+			   ar->wmi.svc_map)))
+		*rate_ctrl = WMI_PEER_TID_CONFIG_RATE_UPPER_CAP;
+	else
+		return -EOPNOTSUPP;
+	return 0;
+}
+
+static int ath10k_mac_set_tid_config(struct ath10k *ar, struct ieee80211_sta *sta,
+				     struct ieee80211_vif *vif, u32 changed,
+				     struct wmi_per_peer_per_tid_cfg_arg *arg)
+{
+	struct ath10k_vif *arvif = (void *)vif->drv_priv;
+	struct ath10k_sta *arsta;
+	int ret;
+
+	if (sta) {
+		if (!sta->wme)
+			return -ENOTSUPP;
+
+		arsta = (struct ath10k_sta *)sta->drv_priv;
+
+		if (changed & BIT(NL80211_TID_CONFIG_ATTR_NOACK)) {
+			if ((arsta->retry_long[arg->tid] > 0 ||
+			     arsta->rate_code[arg->tid] > 0 ||
+			     arsta->ampdu[arg->tid] ==
+					WMI_TID_CONFIG_AGGR_CONTROL_ENABLE) &&
+			     arg->ack_policy == WMI_PEER_TID_CONFIG_NOACK) {
+				changed &= ~BIT(NL80211_TID_CONFIG_ATTR_NOACK);
+				arg->ack_policy = 0;
+				arg->aggr_control = 0;
+				arg->rate_ctrl = 0;
+				arg->rcode_flags = 0;
+			}
+		}
+
+		if (changed & BIT(NL80211_TID_CONFIG_ATTR_AMPDU_CTRL)) {
+			if (arsta->noack[arg->tid] == WMI_PEER_TID_CONFIG_NOACK ||
+			    arvif->noack[arg->tid] == WMI_PEER_TID_CONFIG_NOACK) {
+				arg->aggr_control = 0;
+				changed &= ~BIT(NL80211_TID_CONFIG_ATTR_RETRY_LONG);
+			}
+		}
+
+		if (changed & (BIT(NL80211_TID_CONFIG_ATTR_TX_RATE) |
+		    BIT(NL80211_TID_CONFIG_ATTR_TX_RATE_TYPE))) {
+			if (arsta->noack[arg->tid] == WMI_PEER_TID_CONFIG_NOACK ||
+			    arvif->noack[arg->tid] == WMI_PEER_TID_CONFIG_NOACK) {
+				arg->rate_ctrl = 0;
+				arg->rcode_flags = 0;
+			}
+		}
+
+		ether_addr_copy(arg->peer_macaddr.addr, sta->addr);
+		ret = ath10k_wmi_set_per_peer_per_tid_cfg(ar, arg);
+		if (ret)
+			return ret;
+
+		/* Store the configured parameters in success case */
+		if (changed & BIT(NL80211_TID_CONFIG_ATTR_NOACK)) {
+			arsta->noack[arg->tid] = arg->ack_policy;
+			arg->ack_policy = 0;
+			arg->aggr_control = 0;
+			arg->rate_ctrl = 0;
+			arg->rcode_flags = 0;
+		}
+
+		if (changed & BIT(NL80211_TID_CONFIG_ATTR_RETRY_LONG)) {
+			arsta->retry_long[arg->tid] = arg->retry_count;
+			arg->retry_count = 0;
+		}
+
+		if (changed & BIT(NL80211_TID_CONFIG_ATTR_AMPDU_CTRL)) {
+			arsta->ampdu[arg->tid] = arg->aggr_control;
+			arg->aggr_control = 0;
+		}
+
+		if (changed & (BIT(NL80211_TID_CONFIG_ATTR_TX_RATE) |
+		    BIT(NL80211_TID_CONFIG_ATTR_TX_RATE_TYPE))) {
+			arsta->rate_ctrl[arg->tid] = arg->rate_ctrl;
+			arg->rate_ctrl = 0;
+			arg->rcode_flags = 0;
+		}
+
+		if (changed & BIT(NL80211_TID_CONFIG_ATTR_RTSCTS_CTRL)) {
+			arsta->rtscts[arg->tid] = arg->rtscts_ctrl;
+			arg->ext_tid_cfg_bitmap = 0;
+		}
+	} else {
+		if (changed & BIT(NL80211_TID_CONFIG_ATTR_NOACK)) {
+			if ((arvif->retry_long[arg->tid] ||
+			     arvif->rate_code[arg->tid] ||
+			     arvif->ampdu[arg->tid] ==
+					WMI_TID_CONFIG_AGGR_CONTROL_ENABLE) &&
+			     arg->ack_policy == WMI_PEER_TID_CONFIG_NOACK) {
+				changed &= ~BIT(NL80211_TID_CONFIG_ATTR_NOACK);
+			} else {
+				arvif->noack[arg->tid] = arg->ack_policy;
+				arvif->ampdu[arg->tid] = arg->aggr_control;
+				arvif->rate_ctrl[arg->tid] = arg->rate_ctrl;
+			}
+		}
+
+		if (changed & BIT(NL80211_TID_CONFIG_ATTR_RETRY_LONG)) {
+			if (arvif->noack[arg->tid] == WMI_PEER_TID_CONFIG_NOACK)
+				changed &= ~BIT(NL80211_TID_CONFIG_ATTR_RETRY_LONG);
+			else
+				arvif->retry_long[arg->tid] = arg->retry_count;
+		}
+
+		if (changed & BIT(NL80211_TID_CONFIG_ATTR_AMPDU_CTRL)) {
+			if (arvif->noack[arg->tid] == WMI_PEER_TID_CONFIG_NOACK)
+				changed &= ~BIT(NL80211_TID_CONFIG_ATTR_AMPDU_CTRL);
+			else
+				arvif->ampdu[arg->tid] = arg->aggr_control;
+		}
+
+		if (changed & (BIT(NL80211_TID_CONFIG_ATTR_TX_RATE) |
+		    BIT(NL80211_TID_CONFIG_ATTR_TX_RATE_TYPE))) {
+			if (arvif->noack[arg->tid] == WMI_PEER_TID_CONFIG_NOACK) {
+				changed &= ~(BIT(NL80211_TID_CONFIG_ATTR_TX_RATE) |
+					     BIT(NL80211_TID_CONFIG_ATTR_TX_RATE_TYPE));
+			} else {
+				arvif->rate_ctrl[arg->tid] = arg->rate_ctrl;
+				arvif->rate_code[arg->tid] = arg->rcode_flags;
+			}
+		}
+
+		if (changed & BIT(NL80211_TID_CONFIG_ATTR_RTSCTS_CTRL)) {
+			arvif->rtscts[arg->tid] = arg->rtscts_ctrl;
+			arg->ext_tid_cfg_bitmap = 0;
+		}
+
+		if (changed)
+			arvif->tid_conf_changed[arg->tid] |= changed;
+	}
+
+	return 0;
+}
+
+static int
+ath10k_mac_parse_tid_config(struct ath10k *ar,
+			    struct ieee80211_sta *sta,
+			    struct ieee80211_vif *vif,
+			    struct cfg80211_tid_cfg *tid_conf,
+			    struct wmi_per_peer_per_tid_cfg_arg *arg)
+{
+	u32 changed = tid_conf->mask;
+	int ret = 0, i = 0;
+
+	if (!changed)
+		return -EINVAL;
+
+	while (i < ATH10K_TID_MAX) {
+		if (!(tid_conf->tids & BIT(i))) {
+			i++;
+			continue;
+		}
+
+		arg->tid = i;
+
+		if (changed & BIT(NL80211_TID_CONFIG_ATTR_NOACK)) {
+			if (tid_conf->noack == NL80211_TID_CONFIG_ENABLE) {
+				arg->ack_policy = WMI_PEER_TID_CONFIG_NOACK;
+				arg->rate_ctrl =
+				WMI_TID_CONFIG_RATE_CONTROL_DEFAULT_LOWEST_RATE;
+				arg->aggr_control =
+					WMI_TID_CONFIG_AGGR_CONTROL_DISABLE;
+			} else {
+				arg->ack_policy =
+					WMI_PEER_TID_CONFIG_ACK;
+				arg->rate_ctrl =
+					WMI_TID_CONFIG_RATE_CONTROL_AUTO;
+				arg->aggr_control =
+					WMI_TID_CONFIG_AGGR_CONTROL_ENABLE;
+			}
+		}
+
+		if (changed & BIT(NL80211_TID_CONFIG_ATTR_RETRY_LONG))
+			arg->retry_count = tid_conf->retry_long;
+
+		if (changed & BIT(NL80211_TID_CONFIG_ATTR_AMPDU_CTRL)) {
+			if (tid_conf->noack == NL80211_TID_CONFIG_ENABLE)
+				arg->aggr_control = WMI_TID_CONFIG_AGGR_CONTROL_ENABLE;
+			else
+				arg->aggr_control = WMI_TID_CONFIG_AGGR_CONTROL_DISABLE;
+		}
+
+		if (changed & (BIT(NL80211_TID_CONFIG_ATTR_TX_RATE) |
+		    BIT(NL80211_TID_CONFIG_ATTR_TX_RATE_TYPE))) {
+			ret = ath10k_mac_tid_bitrate_config(ar, vif, sta,
+							    &arg->rcode_flags,
+							    &arg->rate_ctrl,
+							    tid_conf->txrate_type,
+							&tid_conf->txrate_mask);
+			if (ret) {
+				ath10k_warn(ar, "failed to configure bitrate mask %d\n",
+					    ret);
+				arg->rcode_flags = 0;
+				arg->rate_ctrl = 0;
+			}
+		}
+
+		if (changed & BIT(NL80211_TID_CONFIG_ATTR_RTSCTS_CTRL)) {
+			if (tid_conf->rtscts)
+				arg->rtscts_ctrl = tid_conf->rtscts;
+
+			arg->ext_tid_cfg_bitmap = WMI_EXT_TID_RTS_CTS_CONFIG;
+		}
+
+		ret = ath10k_mac_set_tid_config(ar, sta, vif, changed, arg);
+		if (ret)
+			return ret;
+		i++;
+	}
+	return ret;
+}
+
+static void ath10k_sta_tid_cfg_wk(struct work_struct *wk)
+{
+	struct wmi_per_peer_per_tid_cfg_arg arg = {};
+	struct ieee80211_sta *sta;
+	struct ath10k_sta *arsta;
+	struct ath10k_vif *arvif;
+	struct ath10k *ar;
+	bool config_apply;
+	int ret, i;
+	u32 changed;
+
+	arsta = container_of(wk, struct ath10k_sta, tid_config_wk);
+	sta = container_of((void *)arsta, struct ieee80211_sta, drv_priv);
+	arvif = arsta->arvif;
+	ar = arvif->ar;
+
+	mutex_lock(&ar->conf_mutex);
+
+	ether_addr_copy(arg.peer_macaddr.addr, sta->addr);
+	for (i = 0; i < ATH10K_TID_MAX; i++) {
+		config_apply = false;
+		changed = arvif->tid_conf_changed[i];
+
+		if (changed & BIT(NL80211_TID_CONFIG_ATTR_NOACK)) {
+			if (arsta->noack[i] != -1) {
+				arg.ack_policy  = 0;
+			} else {
+				config_apply = true;
+				arg.ack_policy = arvif->noack[i];
+				arg.aggr_control = arvif->ampdu[i];
+				arg.rate_ctrl = arvif->rate_ctrl[i];
+			}
+		}
+
+		if (changed & BIT(NL80211_TID_CONFIG_ATTR_RETRY_LONG)) {
+			if (arsta->retry_long[i] != -1 ||
+			    arsta->noack[i] == WMI_PEER_TID_CONFIG_NOACK ||
+			    arvif->noack[i] == WMI_PEER_TID_CONFIG_NOACK) {
+				arg.retry_count = 0;
+			} else {
+				arg.retry_count = arvif->retry_long[i];
+				config_apply = true;
+			}
+		}
+
+		if (changed & BIT(NL80211_TID_CONFIG_ATTR_AMPDU_CTRL)) {
+			if (arsta->ampdu[i] != -1 ||
+			    arsta->noack[i] == WMI_PEER_TID_CONFIG_NOACK ||
+			    arvif->noack[i] == WMI_PEER_TID_CONFIG_NOACK) {
+				arg.aggr_control = 0;
+			} else {
+				arg.aggr_control = arvif->ampdu[i];
+				config_apply = true;
+			}
+		}
+
+		if (changed & (BIT(NL80211_TID_CONFIG_ATTR_TX_RATE) |
+		    BIT(NL80211_TID_CONFIG_ATTR_TX_RATE_TYPE))) {
+			if (arvif->rate_ctrl[i] > WMI_TID_CONFIG_RATE_CONTROL_AUTO &&
+			    ath10k_mac_validate_rate_mask(ar, sta, arvif->rate_code[i],
+						ATH10K_HW_NSS(arvif->rate_code[i]))) {
+				arg.rate_ctrl = 0;
+				arg.rcode_flags = 0;
+			}
+
+			if (arsta->rate_ctrl[i] >
+			    WMI_TID_CONFIG_RATE_CONTROL_AUTO ||
+			    arsta->noack[i] == WMI_PEER_TID_CONFIG_NOACK ||
+			    arvif->noack[i] == WMI_PEER_TID_CONFIG_NOACK) {
+				arg.rate_ctrl = 0;
+				arg.rcode_flags = 0;
+			} else {
+				arg.rate_ctrl = arvif->rate_ctrl[i];
+				arg.rcode_flags = arvif->rate_code[i];
+				config_apply = true;
+			}
+		}
+
+		if (changed & BIT(NL80211_TID_CONFIG_ATTR_RTSCTS_CTRL)) {
+			if (arsta->rtscts[i]) {
+				arg.rtscts_ctrl = 0;
+				arg.ext_tid_cfg_bitmap = 0;
+			} else {
+				arg.rtscts_ctrl = arvif->rtscts[i] - 1;
+				arg.ext_tid_cfg_bitmap =
+					WMI_EXT_TID_RTS_CTS_CONFIG;
+				config_apply = true;
+			}
+		}
+
+		arg.tid = i;
+
+		if (config_apply) {
+			ret = ath10k_wmi_set_per_peer_per_tid_cfg(ar, &arg);
+			if (ret)
+				ath10k_warn(ar, "failed to set per tid config for sta %pM: %d\n",
+					    sta->addr, ret);
+		}
+
+		arg.ack_policy  = 0;
+		arg.retry_count  = 0;
+		arg.aggr_control  = 0;
+		arg.rate_ctrl = 0;
+		arg.rcode_flags = 0;
+	}
+
+	mutex_unlock(&ar->conf_mutex);
+}
+
+static void ath10k_mac_vif_stations_tid_conf(void *data,
+					     struct ieee80211_sta *sta)
+{
+	struct ath10k_sta *arsta = (struct ath10k_sta *)sta->drv_priv;
+	struct ath10k_mac_iter_tid_conf_data *iter_data = data;
+	struct ieee80211_vif *sta_vif = arsta->arvif->vif;
+
+	if (sta_vif != iter_data->curr_vif || !sta->wme)
+		return;
+
+	ieee80211_queue_work(iter_data->ar->hw, &arsta->tid_config_wk);
+}
+
 static int ath10k_sta_state(struct ieee80211_hw *hw,
 			    struct ieee80211_vif *vif,
 			    struct ieee80211_sta *sta,
@@ -6708,6 +7212,7 @@ static int ath10k_sta_state(struct ieee80211_hw *hw,
 		arsta->arvif = arvif;
 		arsta->peer_ps_state = WMI_PEER_PS_STATE_DISABLED;
 		INIT_WORK(&arsta->update_wk, ath10k_sta_rc_update_wk);
+		INIT_WORK(&arsta->tid_config_wk, ath10k_sta_tid_cfg_wk);
 
 		for (i = 0; i < ARRAY_SIZE(sta->txq); i++)
 			ath10k_mac_txq_init(sta->txq[i]);
@@ -6715,8 +7220,10 @@ static int ath10k_sta_state(struct ieee80211_hw *hw,
 
 	/* cancel must be done outside the mutex to avoid deadlock */
 	if ((old_state == IEEE80211_STA_NONE &&
-	     new_state == IEEE80211_STA_NOTEXIST))
+	     new_state == IEEE80211_STA_NOTEXIST)) {
 		cancel_work_sync(&arsta->update_wk);
+		cancel_work_sync(&arsta->tid_config_wk);
+	}
 
 	mutex_lock(&ar->conf_mutex);
 
@@ -8557,6 +9064,45 @@ static void ath10k_sta_statistics(struct ieee80211_hw *hw,
 	ath10k_mac_sta_get_peer_stats_info(ar, sta, sinfo);
 }
 
+static int ath10k_mac_op_set_tid_config(struct ieee80211_hw *hw,
+					struct ieee80211_vif *vif,
+					struct ieee80211_sta *sta,
+					struct cfg80211_tid_config *tid_config)
+{
+	struct ath10k *ar = hw->priv;
+	struct ath10k_vif *arvif = (void *)vif->drv_priv;
+	struct ath10k_mac_iter_tid_conf_data data = {};
+	struct wmi_per_peer_per_tid_cfg_arg arg = {};
+	int ret, i;
+
+	mutex_lock(&ar->conf_mutex);
+	arg.vdev_id = arvif->vdev_id;
+
+	memset(arvif->tid_conf_changed, 0, sizeof(arvif->tid_conf_changed));
+
+	for (i = 0; i < tid_config->n_tid_conf; i++) {
+		ret = ath10k_mac_parse_tid_config(ar, sta, vif,
+						  &tid_config->tid_conf[i],
+						  &arg);
+		if (ret)
+			goto exit;
+	}
+
+	if (sta)
+		goto exit;
+
+	ret = 0;
+	data.curr_vif = vif;
+	data.ar = ar;
+
+	ieee80211_iterate_stations_atomic(hw, ath10k_mac_vif_stations_tid_conf,
+					  &data);
+
+exit:
+	mutex_unlock(&ar->conf_mutex);
+	return ret;
+}
+
 static const struct ieee80211_ops ath10k_ops = {
 	.tx				= ath10k_mac_op_tx,
 	.wake_tx_queue			= ath10k_mac_op_wake_tx_queue,
@@ -8600,6 +9146,7 @@ static void ath10k_sta_statistics(struct ieee80211_hw *hw,
 	.switch_vif_chanctx		= ath10k_mac_op_switch_vif_chanctx,
 	.sta_pre_rcu_remove		= ath10k_mac_op_sta_pre_rcu_remove,
 	.sta_statistics			= ath10k_sta_statistics,
+	.set_tid_config			= ath10k_mac_op_set_tid_config,
 
 	CFG80211_TESTMODE_CMD(ath10k_tm_cmd)
 
@@ -9270,6 +9817,28 @@ int ath10k_mac_register(struct ath10k *ar)
 	if (test_bit(WMI_SERVICE_TX_PWR_PER_PEER, ar->wmi.svc_map))
 		wiphy_ext_feature_set(ar->hw->wiphy,
 				      NL80211_EXT_FEATURE_STA_TX_PWR);
+
+	if (test_bit(WMI_SERVICE_PEER_TID_CONFIGS_SUPPORT, ar->wmi.svc_map)) {
+		ar->hw->wiphy->tid_config_support.vif |=
+				BIT(NL80211_TID_CONFIG_ATTR_NOACK) |
+				BIT(NL80211_TID_CONFIG_ATTR_RETRY_SHORT) |
+				BIT(NL80211_TID_CONFIG_ATTR_RETRY_LONG) |
+				BIT(NL80211_TID_CONFIG_ATTR_AMPDU_CTRL) |
+				BIT(NL80211_TID_CONFIG_ATTR_TX_RATE) |
+				BIT(NL80211_TID_CONFIG_ATTR_TX_RATE_TYPE);
+
+		if (test_bit(WMI_SERVICE_EXT_PEER_TID_CONFIGS_SUPPORT,
+			     ar->wmi.svc_map)) {
+			ar->hw->wiphy->tid_config_support.vif |=
+				BIT(NL80211_TID_CONFIG_ATTR_RTSCTS_CTRL);
+		}
+
+		ar->hw->wiphy->tid_config_support.peer =
+				ar->hw->wiphy->tid_config_support.vif;
+		ar->hw->wiphy->max_data_retry_count = ATH10K_MAX_RETRY_COUNT;
+	} else {
+		ar->ops->set_tid_config = NULL;
+	}
 	/*
 	 * on LL hardware queues are managed entirely by the FW
 	 * so we only advertise to mac we can do the queues thing
diff --git a/drivers/net/wireless/ath/ath10k/txrx.c b/drivers/net/wireless/ath/ath10k/txrx.c
index f46b908..aefe1f7 100644
--- a/drivers/net/wireless/ath/ath10k/txrx.c
+++ b/drivers/net/wireless/ath/ath10k/txrx.c
@@ -50,6 +50,7 @@ int ath10k_txrx_tx_unref(struct ath10k_htt *htt,
 	struct ath10k_skb_cb *skb_cb;
 	struct ath10k_txq *artxq;
 	struct sk_buff *msdu;
+	u8 flags;
 
 	ath10k_dbg(ar, ATH10K_DBG_HTT,
 		   "htt tx completion msdu_id %u status %d\n",
@@ -78,6 +79,7 @@ int ath10k_txrx_tx_unref(struct ath10k_htt *htt,
 		artxq->num_fw_queued--;
 	}
 
+	flags = skb_cb->flags;
 	ath10k_htt_tx_free_msdu_id(htt, tx_done->msdu_id);
 	ath10k_htt_tx_dec_pending(htt);
 	if (htt->num_pending_tx == 0)
@@ -101,18 +103,21 @@ int ath10k_txrx_tx_unref(struct ath10k_htt *htt,
 
 	trace_ath10k_txrx_tx_unref(ar, tx_done->msdu_id);
 
-	if (!(info->flags & IEEE80211_TX_CTL_NO_ACK))
+	if (!(info->flags & IEEE80211_TX_CTL_NO_ACK) &&
+	    !(flags & ATH10K_SKB_F_NOACK_TID))
 		info->flags |= IEEE80211_TX_STAT_ACK;
 
 	if (tx_done->status == HTT_TX_COMPL_STATE_NOACK)
 		info->flags &= ~IEEE80211_TX_STAT_ACK;
 
 	if ((tx_done->status == HTT_TX_COMPL_STATE_ACK) &&
-	    (info->flags & IEEE80211_TX_CTL_NO_ACK))
+	    ((info->flags & IEEE80211_TX_CTL_NO_ACK) ||
+	    (flags & ATH10K_SKB_F_NOACK_TID)))
 		info->flags |= IEEE80211_TX_STAT_NOACK_TRANSMITTED;
 
 	if (tx_done->status == HTT_TX_COMPL_STATE_DISCARD) {
-		if (info->flags & IEEE80211_TX_CTL_NO_ACK)
+		if ((info->flags & IEEE80211_TX_CTL_NO_ACK) ||
+		    (flags & ATH10K_SKB_F_NOACK_TID))
 			info->flags &= ~IEEE80211_TX_STAT_NOACK_TRANSMITTED;
 		else
 			info->flags &= ~IEEE80211_TX_STAT_ACK;
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 4316551..a489cfb 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -9027,11 +9027,14 @@ static u32 ath10k_wmi_prepare_peer_qos(u8 uapsd_queues, u8 sp)
 	cmd->rate_control = cpu_to_le32(arg->rate_ctrl);
 	cmd->retry_count = cpu_to_le32(arg->retry_count);
 	cmd->rcode_flags = cpu_to_le32(arg->rcode_flags);
+	cmd->ext_tid_cfg_bitmap = cpu_to_le32(arg->ext_tid_cfg_bitmap);
+	cmd->rtscts_ctrl = cpu_to_le32(arg->rtscts_ctrl);
 
 	ath10k_dbg(ar, ATH10K_DBG_WMI,
-		   "wmi noack tid %d vdev id %d ack_policy %d aggr %u rate_ctrl %u rcflag %u retry_count %d mac_addr %pM\n",
-		   arg->tid, arg->vdev_id, arg->ack_policy, arg->aggr_control, arg->rate_ctrl,
-		   arg->rcode_flags, arg->retry_count, arg->peer_macaddr.addr);
+		   "wmi noack tid %d vdev id %d ack_policy %d aggr %u rate_ctrl %u rcflag %u retry_count %d rtscts %d ext_tid_cfg_bitmap %d mac_addr %pM\n",
+		   arg->tid, arg->vdev_id, arg->ack_policy, arg->aggr_control,
+		   arg->rate_ctrl, arg->rcode_flags, arg->retry_count, arg->rtscts_ctrl,
+		   arg->ext_tid_cfg_bitmap, arg->peer_macaddr.addr);
 	return skb;
 }
 
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index 7fed735..ed5ff67 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -204,6 +204,7 @@ enum wmi_service {
 	WMI_SERVICE_TX_PWR_PER_PEER,
 	WMI_SERVICE_SUPPORT_EXTEND_ADDRESS,
 	WMI_SERVICE_PEER_TID_CONFIGS_SUPPORT,
+	WMI_SERVICE_EXT_PEER_TID_CONFIGS_SUPPORT,
 
 	/* Remember to add the new value to wmi_service_name()! */
 
@@ -505,6 +506,7 @@ static inline char *wmi_service_name(enum wmi_service service_id)
 	SVCSTR(WMI_SERVICE_TX_PWR_PER_PEER);
 	SVCSTR(WMI_SERVICE_SUPPORT_EXTEND_ADDRESS);
 	SVCSTR(WMI_SERVICE_PEER_TID_CONFIGS_SUPPORT);
+	SVCSTR(WMI_SERVICE_EXT_PEER_TID_CONFIGS_SUPPORT);
 
 	case WMI_SERVICE_MAX:
 		return NULL;
@@ -838,6 +840,8 @@ static inline void wmi_10_4_svc_map(const __le32 *in, unsigned long *out,
 	       WMI_SERVICE_RESET_CHIP, len);
 	SVCMAP(WMI_10_4_SERVICE_PEER_TID_CONFIGS_SUPPORT,
 	       WMI_SERVICE_PEER_TID_CONFIGS_SUPPORT, len);
+	SVCMAP(WMI_10_4_SERVICE_EXT_PEER_TID_CONFIGS_SUPPORT,
+	       WMI_SERVICE_PEER_TID_CONFIGS_SUPPORT, len);
 }
 
 #undef SVCMAP
@@ -7244,6 +7248,16 @@ enum wmi_tid_rate_ctrl_conf {
 	WMI_TID_CONFIG_RATE_CONTROL_AUTO,
 	WMI_TID_CONFIG_RATE_CONTROL_FIXED_RATE,
 	WMI_TID_CONFIG_RATE_CONTROL_DEFAULT_LOWEST_RATE,
+	WMI_PEER_TID_CONFIG_RATE_UPPER_CAP,
+};
+
+enum wmi_tid_rtscts_control_conf {
+	WMI_TID_CONFIG_RTSCTS_CONTROL_ENABLE,
+	WMI_TID_CONFIG_RTSCTS_CONTROL_DISABLE,
+};
+
+enum wmi_ext_tid_config_map {
+	WMI_EXT_TID_RTS_CTS_CONFIG = BIT(0),
 };
 
 struct wmi_per_peer_per_tid_cfg_arg {
@@ -7255,6 +7269,8 @@ struct wmi_per_peer_per_tid_cfg_arg {
 	u8 rate_ctrl;
 	u32 retry_count;
 	u32 rcode_flags;
+	u32 ext_tid_cfg_bitmap;
+	u32 rtscts_ctrl;
 };
 
 struct wmi_peer_per_tid_cfg_cmd {
@@ -7270,6 +7286,10 @@ struct wmi_peer_per_tid_cfg_cmd {
 	__le32 rate_control;
 	__le32 rcode_flags;
 	__le32 retry_count;
+	/* See enum wmi_ext_tid_config_map */
+	__le32 ext_tid_cfg_bitmap;
+	/* see enum wmi_tid_rtscts_control_conf */
+	__le32 rtscts_ctrl;
 } __packed;
 
 enum wmi_txbf_conf {
-- 
1.9.1



From dianders at chromium.org  Tue Jul  7 13:17:34 2020
From: dianders at chromium.org (Douglas Anderson)
Date: Tue,  7 Jul 2020 10:17:34 -0700
Subject: [PATCH] ath10k: Keep track of which interrupts fired, don't poll them
Message-ID: <20200707101712.1.I4d2f85ffa06f38532631e864a3125691ef5ffe06@changeid>

If we have a per CE (Copy Engine) IRQ then we have no summary
register.  Right now the code generates a summary register by
iterating over all copy engines and seeing if they have an interrupt
pending.

This has a problem.  Specifically if _none_ if the Copy Engines have
an interrupt pending then they might go into low power mode and
reading from their address space will cause a full system crash.  This
was seen to happen when two interrupts went off at nearly the same
time.  Both were handled by a single call of ath10k_snoc_napi_poll()
but, because there were two interrupts handled and thus two calls to
napi_schedule() there was still a second call to
ath10k_snoc_napi_poll() which ran with no interrupts pending.

Instead of iterating over all the copy engines, let's just keep track
of the IRQs that fire.  Then we can effectively generate our own
summary without ever needing to read the Copy Engines.

Tested-on: WCN3990 SNOC WLAN.HL.3.2.2-00490-QCAHLSWMTPL-1

Signed-off-by: Douglas Anderson <dianders at chromium.org>
---
This patch continues work to try to squash all instances of the crash
we've been seeing while reading CE registers and hopefully this patch
addresses the true root of the issue.

The first patch that attempted to address these problems landed as
commit 8f9ed93d09a9 ("ath10k: Wait until copy complete is actually
done before completing").  After that Rakesh Pillai posted ("ath10k:
Add interrupt summary based CE processing") [1] and this patch is
based atop that one.  Both of those patches significantly reduced the
instances of problems but didn't fully eliminate them.  Crossing my
fingers that they're all gone now.

[1] https://lore.kernel.org/r/1593193967-29897-1-git-send-email-pillair at codeaurora.org

 drivers/net/wireless/ath/ath10k/ce.c   | 84 ++++++++++----------------
 drivers/net/wireless/ath/ath10k/ce.h   | 14 ++---
 drivers/net/wireless/ath/ath10k/snoc.c | 18 ++++--
 drivers/net/wireless/ath/ath10k/snoc.h |  1 +
 4 files changed, 51 insertions(+), 66 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/ce.c b/drivers/net/wireless/ath/ath10k/ce.c
index 1e16f263854a..84ec80c6d08f 100644
--- a/drivers/net/wireless/ath/ath10k/ce.c
+++ b/drivers/net/wireless/ath/ath10k/ce.c
@@ -481,38 +481,6 @@ static inline void ath10k_ce_engine_int_status_clear(struct ath10k *ar,
 	ath10k_ce_write32(ar, ce_ctrl_addr + wm_regs->addr, mask);
 }
 
-static bool ath10k_ce_engine_int_status_check(struct ath10k *ar, u32 ce_ctrl_addr,
-					      unsigned int mask)
-{
-	struct ath10k_hw_ce_host_wm_regs *wm_regs = ar->hw_ce_regs->wm_regs;
-
-	return ath10k_ce_read32(ar, ce_ctrl_addr + wm_regs->addr) & mask;
-}
-
-u32 ath10k_ce_gen_interrupt_summary(struct ath10k *ar)
-{
-	struct ath10k_hw_ce_host_wm_regs *wm_regs = ar->hw_ce_regs->wm_regs;
-	struct ath10k_ce_pipe *ce_state;
-	struct ath10k_ce *ce;
-	u32 irq_summary = 0;
-	u32 ctrl_addr;
-	u32 ce_id;
-
-	ce = ath10k_ce_priv(ar);
-
-	for (ce_id = 0; ce_id < CE_COUNT; ce_id++) {
-		ce_state = &ce->ce_states[ce_id];
-		ctrl_addr = ce_state->ctrl_addr;
-		if (ath10k_ce_engine_int_status_check(ar, ctrl_addr,
-						      wm_regs->cc_mask)) {
-			irq_summary |= BIT(ce_id);
-		}
-	}
-
-	return irq_summary;
-}
-EXPORT_SYMBOL(ath10k_ce_gen_interrupt_summary);
-
 /*
  * Guts of ath10k_ce_send.
  * The caller takes responsibility for any needed locking.
@@ -1399,45 +1367,55 @@ static void ath10k_ce_per_engine_handler_adjust(struct ath10k_ce_pipe *ce_state)
 	ath10k_ce_watermark_intr_disable(ar, ctrl_addr);
 }
 
-int ath10k_ce_disable_interrupts(struct ath10k *ar)
+void ath10k_ce_disable_interrupt(struct ath10k *ar, int ce_id)
 {
 	struct ath10k_ce *ce = ath10k_ce_priv(ar);
 	struct ath10k_ce_pipe *ce_state;
 	u32 ctrl_addr;
-	int ce_id;
 
-	for (ce_id = 0; ce_id < CE_COUNT; ce_id++) {
-		ce_state  = &ce->ce_states[ce_id];
-		if (ce_state->attr_flags & CE_ATTR_POLL)
-			continue;
+	ce_state  = &ce->ce_states[ce_id];
+	if (ce_state->attr_flags & CE_ATTR_POLL)
+		return;
 
-		ctrl_addr = ath10k_ce_base_address(ar, ce_id);
+	ctrl_addr = ath10k_ce_base_address(ar, ce_id);
 
-		ath10k_ce_copy_complete_intr_disable(ar, ctrl_addr);
-		ath10k_ce_error_intr_disable(ar, ctrl_addr);
-		ath10k_ce_watermark_intr_disable(ar, ctrl_addr);
-	}
+	ath10k_ce_copy_complete_intr_disable(ar, ctrl_addr);
+	ath10k_ce_error_intr_disable(ar, ctrl_addr);
+	ath10k_ce_watermark_intr_disable(ar, ctrl_addr);
+}
+EXPORT_SYMBOL(ath10k_ce_disable_interrupt);
 
-	return 0;
+void ath10k_ce_disable_interrupts(struct ath10k *ar)
+{
+	int ce_id;
+
+	for (ce_id = 0; ce_id < CE_COUNT; ce_id++)
+		ath10k_ce_disable_interrupt(ar, ce_id);
 }
 EXPORT_SYMBOL(ath10k_ce_disable_interrupts);
 
-void ath10k_ce_enable_interrupts(struct ath10k *ar)
+void ath10k_ce_enable_interrupt(struct ath10k *ar, int ce_id)
 {
 	struct ath10k_ce *ce = ath10k_ce_priv(ar);
-	int ce_id;
 	struct ath10k_ce_pipe *ce_state;
 
+	ce_state  = &ce->ce_states[ce_id];
+	if (ce_state->attr_flags & CE_ATTR_POLL)
+		return;
+
+	ath10k_ce_per_engine_handler_adjust(ce_state);
+}
+EXPORT_SYMBOL(ath10k_ce_enable_interrupt);
+
+void ath10k_ce_enable_interrupts(struct ath10k *ar)
+{
+	int ce_id;
+
 	/* Enable interrupts for copy engine that
 	 * are not using polling mode.
 	 */
-	for (ce_id = 0; ce_id < CE_COUNT; ce_id++) {
-		ce_state  = &ce->ce_states[ce_id];
-		if (ce_state->attr_flags & CE_ATTR_POLL)
-			continue;
-
-		ath10k_ce_per_engine_handler_adjust(ce_state);
-	}
+	for (ce_id = 0; ce_id < CE_COUNT; ce_id++)
+		ath10k_ce_enable_interrupt(ar, ce_id);
 }
 EXPORT_SYMBOL(ath10k_ce_enable_interrupts);
 
diff --git a/drivers/net/wireless/ath/ath10k/ce.h b/drivers/net/wireless/ath/ath10k/ce.h
index a440aaf74aa4..666ce384a1d8 100644
--- a/drivers/net/wireless/ath/ath10k/ce.h
+++ b/drivers/net/wireless/ath/ath10k/ce.h
@@ -255,12 +255,13 @@ int ath10k_ce_cancel_send_next(struct ath10k_ce_pipe *ce_state,
 /*==================CE Interrupt Handlers====================*/
 void ath10k_ce_per_engine_service_any(struct ath10k *ar);
 void ath10k_ce_per_engine_service(struct ath10k *ar, unsigned int ce_id);
-int ath10k_ce_disable_interrupts(struct ath10k *ar);
+void ath10k_ce_disable_interrupt(struct ath10k *ar, int ce_id);
+void ath10k_ce_disable_interrupts(struct ath10k *ar);
+void ath10k_ce_enable_interrupt(struct ath10k *ar, int ce_id);
 void ath10k_ce_enable_interrupts(struct ath10k *ar);
 void ath10k_ce_dump_registers(struct ath10k *ar,
 			      struct ath10k_fw_crash_data *crash_data);
 
-u32 ath10k_ce_gen_interrupt_summary(struct ath10k *ar);
 void ath10k_ce_alloc_rri(struct ath10k *ar);
 void ath10k_ce_free_rri(struct ath10k *ar);
 
@@ -376,12 +377,9 @@ static inline u32 ath10k_ce_interrupt_summary(struct ath10k *ar)
 {
 	struct ath10k_ce *ce = ath10k_ce_priv(ar);
 
-	if (!ar->hw_params.per_ce_irq)
-		return CE_WRAPPER_INTERRUPT_SUMMARY_HOST_MSI_GET(
-			ce->bus_ops->read32((ar), CE_WRAPPER_BASE_ADDRESS +
-			CE_WRAPPER_INTERRUPT_SUMMARY_ADDRESS));
-	else
-		return ath10k_ce_gen_interrupt_summary(ar);
+	return CE_WRAPPER_INTERRUPT_SUMMARY_HOST_MSI_GET(
+		ce->bus_ops->read32((ar), CE_WRAPPER_BASE_ADDRESS +
+		CE_WRAPPER_INTERRUPT_SUMMARY_ADDRESS));
 }
 
 /* Host software's Copy Engine configuration. */
diff --git a/drivers/net/wireless/ath/ath10k/snoc.c b/drivers/net/wireless/ath/ath10k/snoc.c
index 354d49b1cd45..2fc4dcbab70a 100644
--- a/drivers/net/wireless/ath/ath10k/snoc.c
+++ b/drivers/net/wireless/ath/ath10k/snoc.c
@@ -3,6 +3,7 @@
  * Copyright (c) 2018 The Linux Foundation. All rights reserved.
  */
 
+#include <linux/bits.h>
 #include <linux/clk.h>
 #include <linux/kernel.h>
 #include <linux/module.h>
@@ -1158,7 +1159,9 @@ static irqreturn_t ath10k_snoc_per_engine_handler(int irq, void *arg)
 		return IRQ_HANDLED;
 	}
 
-	ath10k_snoc_irq_disable(ar);
+	ath10k_ce_disable_interrupt(ar, ce_id);
+	set_bit(ce_id, ar_snoc->pending_ce_irqs);
+
 	napi_schedule(&ar->napi);
 
 	return IRQ_HANDLED;
@@ -1167,20 +1170,25 @@ static irqreturn_t ath10k_snoc_per_engine_handler(int irq, void *arg)
 static int ath10k_snoc_napi_poll(struct napi_struct *ctx, int budget)
 {
 	struct ath10k *ar = container_of(ctx, struct ath10k, napi);
+	struct ath10k_snoc *ar_snoc = ath10k_snoc_priv(ar);
 	int done = 0;
+	int ce_id;
 
 	if (test_bit(ATH10K_FLAG_CRASH_FLUSH, &ar->dev_flags)) {
 		napi_complete(ctx);
 		return done;
 	}
 
-	ath10k_ce_per_engine_service_any(ar);
+	for (ce_id = 0; ce_id < CE_COUNT; ce_id++)
+		if (test_and_clear_bit(ce_id, ar_snoc->pending_ce_irqs)) {
+			ath10k_ce_per_engine_service(ar, ce_id);
+			ath10k_ce_enable_interrupt(ar, ce_id);
+		}
+
 	done = ath10k_htt_txrx_compl_task(ar, budget);
 
-	if (done < budget) {
+	if (done < budget)
 		napi_complete(ctx);
-		ath10k_snoc_irq_enable(ar);
-	}
 
 	return done;
 }
diff --git a/drivers/net/wireless/ath/ath10k/snoc.h b/drivers/net/wireless/ath/ath10k/snoc.h
index a3dd06f6ac62..5095d1893681 100644
--- a/drivers/net/wireless/ath/ath10k/snoc.h
+++ b/drivers/net/wireless/ath/ath10k/snoc.h
@@ -78,6 +78,7 @@ struct ath10k_snoc {
 	unsigned long flags;
 	bool xo_cal_supported;
 	u32 xo_cal_data;
+	DECLARE_BITMAP(pending_ce_irqs, CE_COUNT_MAX);
 };
 
 static inline struct ath10k_snoc *ath10k_snoc_priv(struct ath10k *ar)
-- 
2.27.0.383.g050319c2ae-goog



From pillair at codeaurora.org  Wed Jul  8 04:57:23 2020
From: pillair at codeaurora.org (Rakesh Pillai)
Date: Wed, 8 Jul 2020 14:27:23 +0530
Subject: [PATCH] ath10k: Keep track of which interrupts fired,
 don't poll them
In-Reply-To: <20200707101712.1.I4d2f85ffa06f38532631e864a3125691ef5ffe06@changeid>
References: <20200707101712.1.I4d2f85ffa06f38532631e864a3125691ef5ffe06@changeid>
Message-ID: <002901d65505$cf84e980$6e8ebc80$@codeaurora.org>



> -----Original Message-----
> From: Douglas Anderson <dianders at chromium.org>
> Sent: Tuesday, July 7, 2020 10:48 PM
> To: kvalo at codeaurora.org; ath10k at lists.infradead.org
> Cc: saiprakash.ranjan at codeaurora.org; linux-arm-msm at vger.kernel.org;
> linux-wireless at vger.kernel.org; pillair at codeaurora.org;
> kuabhs at google.com; Douglas Anderson <dianders at chromium.org>; David
> S. Miller <davem at davemloft.net>; Jakub Kicinski <kuba at kernel.org>; linux-
> kernel at vger.kernel.org; netdev at vger.kernel.org
> Subject: [PATCH] ath10k: Keep track of which interrupts fired, don't poll
> them
> 
> If we have a per CE (Copy Engine) IRQ then we have no summary
> register.  Right now the code generates a summary register by
> iterating over all copy engines and seeing if they have an interrupt
> pending.
> 
> This has a problem.  Specifically if _none_ if the Copy Engines have
> an interrupt pending then they might go into low power mode and
> reading from their address space will cause a full system crash.  This
> was seen to happen when two interrupts went off at nearly the same
> time.  Both were handled by a single call of ath10k_snoc_napi_poll()
> but, because there were two interrupts handled and thus two calls to
> napi_schedule() there was still a second call to
> ath10k_snoc_napi_poll() which ran with no interrupts pending.
> 
> Instead of iterating over all the copy engines, let's just keep track
> of the IRQs that fire.  Then we can effectively generate our own
> summary without ever needing to read the Copy Engines.
> 
> Tested-on: WCN3990 SNOC WLAN.HL.3.2.2-00490-QCAHLSWMTPL-1
> 
> Signed-off-by: Douglas Anderson <dianders at chromium.org>


Reviewed-by:  Rakesh Pillai <pillair at codeaurora.org> 


> ---
> This patch continues work to try to squash all instances of the crash
> we've been seeing while reading CE registers and hopefully this patch
> addresses the true root of the issue.
> 
> The first patch that attempted to address these problems landed as
> commit 8f9ed93d09a9 ("ath10k: Wait until copy complete is actually
> done before completing").  After that Rakesh Pillai posted ("ath10k:
> Add interrupt summary based CE processing") [1] and this patch is
> based atop that one.  Both of those patches significantly reduced the
> instances of problems but didn't fully eliminate them.  Crossing my
> fingers that they're all gone now.
> 
> [1] https://lore.kernel.org/r/1593193967-29897-1-git-send-email-
> pillair at codeaurora.org
> 
>  drivers/net/wireless/ath/ath10k/ce.c   | 84 ++++++++++----------------
>  drivers/net/wireless/ath/ath10k/ce.h   | 14 ++---
>  drivers/net/wireless/ath/ath10k/snoc.c | 18 ++++--
>  drivers/net/wireless/ath/ath10k/snoc.h |  1 +
>  4 files changed, 51 insertions(+), 66 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath/ath10k/ce.c
> b/drivers/net/wireless/ath/ath10k/ce.c
> index 1e16f263854a..84ec80c6d08f 100644
> --- a/drivers/net/wireless/ath/ath10k/ce.c
> +++ b/drivers/net/wireless/ath/ath10k/ce.c
> @@ -481,38 +481,6 @@ static inline void
> ath10k_ce_engine_int_status_clear(struct ath10k *ar,
>  	ath10k_ce_write32(ar, ce_ctrl_addr + wm_regs->addr, mask);
>  }
> 
> -static bool ath10k_ce_engine_int_status_check(struct ath10k *ar, u32
> ce_ctrl_addr,
> -					      unsigned int mask)
> -{
> -	struct ath10k_hw_ce_host_wm_regs *wm_regs = ar->hw_ce_regs-
> >wm_regs;
> -
> -	return ath10k_ce_read32(ar, ce_ctrl_addr + wm_regs->addr) &
> mask;
> -}
> -
> -u32 ath10k_ce_gen_interrupt_summary(struct ath10k *ar)
> -{
> -	struct ath10k_hw_ce_host_wm_regs *wm_regs = ar->hw_ce_regs-
> >wm_regs;
> -	struct ath10k_ce_pipe *ce_state;
> -	struct ath10k_ce *ce;
> -	u32 irq_summary = 0;
> -	u32 ctrl_addr;
> -	u32 ce_id;
> -
> -	ce = ath10k_ce_priv(ar);
> -
> -	for (ce_id = 0; ce_id < CE_COUNT; ce_id++) {
> -		ce_state = &ce->ce_states[ce_id];
> -		ctrl_addr = ce_state->ctrl_addr;
> -		if (ath10k_ce_engine_int_status_check(ar, ctrl_addr,
> -						      wm_regs->cc_mask)) {
> -			irq_summary |= BIT(ce_id);
> -		}
> -	}
> -
> -	return irq_summary;
> -}
> -EXPORT_SYMBOL(ath10k_ce_gen_interrupt_summary);
> -
>  /*
>   * Guts of ath10k_ce_send.
>   * The caller takes responsibility for any needed locking.
> @@ -1399,45 +1367,55 @@ static void
> ath10k_ce_per_engine_handler_adjust(struct ath10k_ce_pipe *ce_state)
>  	ath10k_ce_watermark_intr_disable(ar, ctrl_addr);
>  }
> 
> -int ath10k_ce_disable_interrupts(struct ath10k *ar)
> +void ath10k_ce_disable_interrupt(struct ath10k *ar, int ce_id)
>  {
>  	struct ath10k_ce *ce = ath10k_ce_priv(ar);
>  	struct ath10k_ce_pipe *ce_state;
>  	u32 ctrl_addr;
> -	int ce_id;
> 
> -	for (ce_id = 0; ce_id < CE_COUNT; ce_id++) {
> -		ce_state  = &ce->ce_states[ce_id];
> -		if (ce_state->attr_flags & CE_ATTR_POLL)
> -			continue;
> +	ce_state  = &ce->ce_states[ce_id];
> +	if (ce_state->attr_flags & CE_ATTR_POLL)
> +		return;
> 
> -		ctrl_addr = ath10k_ce_base_address(ar, ce_id);
> +	ctrl_addr = ath10k_ce_base_address(ar, ce_id);
> 
> -		ath10k_ce_copy_complete_intr_disable(ar, ctrl_addr);
> -		ath10k_ce_error_intr_disable(ar, ctrl_addr);
> -		ath10k_ce_watermark_intr_disable(ar, ctrl_addr);
> -	}
> +	ath10k_ce_copy_complete_intr_disable(ar, ctrl_addr);
> +	ath10k_ce_error_intr_disable(ar, ctrl_addr);
> +	ath10k_ce_watermark_intr_disable(ar, ctrl_addr);
> +}
> +EXPORT_SYMBOL(ath10k_ce_disable_interrupt);
> 
> -	return 0;
> +void ath10k_ce_disable_interrupts(struct ath10k *ar)
> +{
> +	int ce_id;
> +
> +	for (ce_id = 0; ce_id < CE_COUNT; ce_id++)
> +		ath10k_ce_disable_interrupt(ar, ce_id);
>  }
>  EXPORT_SYMBOL(ath10k_ce_disable_interrupts);
> 
> -void ath10k_ce_enable_interrupts(struct ath10k *ar)
> +void ath10k_ce_enable_interrupt(struct ath10k *ar, int ce_id)
>  {
>  	struct ath10k_ce *ce = ath10k_ce_priv(ar);
> -	int ce_id;
>  	struct ath10k_ce_pipe *ce_state;
> 
> +	ce_state  = &ce->ce_states[ce_id];
> +	if (ce_state->attr_flags & CE_ATTR_POLL)
> +		return;
> +
> +	ath10k_ce_per_engine_handler_adjust(ce_state);
> +}
> +EXPORT_SYMBOL(ath10k_ce_enable_interrupt);
> +
> +void ath10k_ce_enable_interrupts(struct ath10k *ar)
> +{
> +	int ce_id;
> +
>  	/* Enable interrupts for copy engine that
>  	 * are not using polling mode.
>  	 */
> -	for (ce_id = 0; ce_id < CE_COUNT; ce_id++) {
> -		ce_state  = &ce->ce_states[ce_id];
> -		if (ce_state->attr_flags & CE_ATTR_POLL)
> -			continue;
> -
> -		ath10k_ce_per_engine_handler_adjust(ce_state);
> -	}
> +	for (ce_id = 0; ce_id < CE_COUNT; ce_id++)
> +		ath10k_ce_enable_interrupt(ar, ce_id);
>  }
>  EXPORT_SYMBOL(ath10k_ce_enable_interrupts);
> 
> diff --git a/drivers/net/wireless/ath/ath10k/ce.h
> b/drivers/net/wireless/ath/ath10k/ce.h
> index a440aaf74aa4..666ce384a1d8 100644
> --- a/drivers/net/wireless/ath/ath10k/ce.h
> +++ b/drivers/net/wireless/ath/ath10k/ce.h
> @@ -255,12 +255,13 @@ int ath10k_ce_cancel_send_next(struct
> ath10k_ce_pipe *ce_state,
>  /*==================CE Interrupt Handlers====================*/
>  void ath10k_ce_per_engine_service_any(struct ath10k *ar);
>  void ath10k_ce_per_engine_service(struct ath10k *ar, unsigned int ce_id);
> -int ath10k_ce_disable_interrupts(struct ath10k *ar);
> +void ath10k_ce_disable_interrupt(struct ath10k *ar, int ce_id);
> +void ath10k_ce_disable_interrupts(struct ath10k *ar);
> +void ath10k_ce_enable_interrupt(struct ath10k *ar, int ce_id);
>  void ath10k_ce_enable_interrupts(struct ath10k *ar);
>  void ath10k_ce_dump_registers(struct ath10k *ar,
>  			      struct ath10k_fw_crash_data *crash_data);
> 
> -u32 ath10k_ce_gen_interrupt_summary(struct ath10k *ar);
>  void ath10k_ce_alloc_rri(struct ath10k *ar);
>  void ath10k_ce_free_rri(struct ath10k *ar);
> 
> @@ -376,12 +377,9 @@ static inline u32
> ath10k_ce_interrupt_summary(struct ath10k *ar)
>  {
>  	struct ath10k_ce *ce = ath10k_ce_priv(ar);
> 
> -	if (!ar->hw_params.per_ce_irq)
> -		return
> CE_WRAPPER_INTERRUPT_SUMMARY_HOST_MSI_GET(
> -			ce->bus_ops->read32((ar),
> CE_WRAPPER_BASE_ADDRESS +
> -			CE_WRAPPER_INTERRUPT_SUMMARY_ADDRESS));
> -	else
> -		return ath10k_ce_gen_interrupt_summary(ar);
> +	return CE_WRAPPER_INTERRUPT_SUMMARY_HOST_MSI_GET(
> +		ce->bus_ops->read32((ar), CE_WRAPPER_BASE_ADDRESS +
> +		CE_WRAPPER_INTERRUPT_SUMMARY_ADDRESS));
>  }
> 
>  /* Host software's Copy Engine configuration. */
> diff --git a/drivers/net/wireless/ath/ath10k/snoc.c
> b/drivers/net/wireless/ath/ath10k/snoc.c
> index 354d49b1cd45..2fc4dcbab70a 100644
> --- a/drivers/net/wireless/ath/ath10k/snoc.c
> +++ b/drivers/net/wireless/ath/ath10k/snoc.c
> @@ -3,6 +3,7 @@
>   * Copyright (c) 2018 The Linux Foundation. All rights reserved.
>   */
> 
> +#include <linux/bits.h>
>  #include <linux/clk.h>
>  #include <linux/kernel.h>
>  #include <linux/module.h>
> @@ -1158,7 +1159,9 @@ static irqreturn_t
> ath10k_snoc_per_engine_handler(int irq, void *arg)
>  		return IRQ_HANDLED;
>  	}
> 
> -	ath10k_snoc_irq_disable(ar);
> +	ath10k_ce_disable_interrupt(ar, ce_id);
> +	set_bit(ce_id, ar_snoc->pending_ce_irqs);
> +
>  	napi_schedule(&ar->napi);
> 
>  	return IRQ_HANDLED;
> @@ -1167,20 +1170,25 @@ static irqreturn_t
> ath10k_snoc_per_engine_handler(int irq, void *arg)
>  static int ath10k_snoc_napi_poll(struct napi_struct *ctx, int budget)
>  {
>  	struct ath10k *ar = container_of(ctx, struct ath10k, napi);
> +	struct ath10k_snoc *ar_snoc = ath10k_snoc_priv(ar);
>  	int done = 0;
> +	int ce_id;
> 
>  	if (test_bit(ATH10K_FLAG_CRASH_FLUSH, &ar->dev_flags)) {
>  		napi_complete(ctx);
>  		return done;
>  	}
> 
> -	ath10k_ce_per_engine_service_any(ar);
> +	for (ce_id = 0; ce_id < CE_COUNT; ce_id++)
> +		if (test_and_clear_bit(ce_id, ar_snoc->pending_ce_irqs)) {
> +			ath10k_ce_per_engine_service(ar, ce_id);
> +			ath10k_ce_enable_interrupt(ar, ce_id);
> +		}
> +
>  	done = ath10k_htt_txrx_compl_task(ar, budget);
> 
> -	if (done < budget) {
> +	if (done < budget)
>  		napi_complete(ctx);
> -		ath10k_snoc_irq_enable(ar);
> -	}
> 
>  	return done;
>  }
> diff --git a/drivers/net/wireless/ath/ath10k/snoc.h
> b/drivers/net/wireless/ath/ath10k/snoc.h
> index a3dd06f6ac62..5095d1893681 100644
> --- a/drivers/net/wireless/ath/ath10k/snoc.h
> +++ b/drivers/net/wireless/ath/ath10k/snoc.h
> @@ -78,6 +78,7 @@ struct ath10k_snoc {
>  	unsigned long flags;
>  	bool xo_cal_supported;
>  	u32 xo_cal_data;
> +	DECLARE_BITMAP(pending_ce_irqs, CE_COUNT_MAX);
>  };
> 
>  static inline struct ath10k_snoc *ath10k_snoc_priv(struct ath10k *ar)
> --
> 2.27.0.383.g050319c2ae-goog




From briannorris at chromium.org  Wed Jul  8 19:03:28 2020
From: briannorris at chromium.org (Brian Norris)
Date: Wed, 8 Jul 2020 16:03:28 -0700
Subject: [PATCH] ath10k: Keep track of which interrupts fired,
 don't poll them
In-Reply-To: <20200707101712.1.I4d2f85ffa06f38532631e864a3125691ef5ffe06@changeid>
References: <20200707101712.1.I4d2f85ffa06f38532631e864a3125691ef5ffe06@changeid>
Message-ID: <CA+ASDXMXtwdV4BNL1GSj8DY-3z8-dZ=1hP8Xv_R-AjKvJs0NMw@mail.gmail.com>

On Tue, Jul 7, 2020 at 10:18 AM Douglas Anderson <dianders at chromium.org> wrote:
> diff --git a/drivers/net/wireless/ath/ath10k/ce.h b/drivers/net/wireless/ath/ath10k/ce.h
> index a440aaf74aa4..666ce384a1d8 100644
> --- a/drivers/net/wireless/ath/ath10k/ce.h
> +++ b/drivers/net/wireless/ath/ath10k/ce.h
...
> @@ -376,12 +377,9 @@ static inline u32 ath10k_ce_interrupt_summary(struct ath10k *ar)
>  {
>         struct ath10k_ce *ce = ath10k_ce_priv(ar);
>
> -       if (!ar->hw_params.per_ce_irq)

If I'm reading correctly, you're removing the only remaining use of
'per_ce_irq'. Should we kill the field entirely? Or perhaps we should
leave some kind of WARN_ON() (BUG_ON()?) if this function is called
erroneously with per_ce_irq==true? But I suppose this driver is full
of landmines if the CE API is used incorrectly.

> -               return CE_WRAPPER_INTERRUPT_SUMMARY_HOST_MSI_GET(
> -                       ce->bus_ops->read32((ar), CE_WRAPPER_BASE_ADDRESS +
> -                       CE_WRAPPER_INTERRUPT_SUMMARY_ADDRESS));
> -       else
> -               return ath10k_ce_gen_interrupt_summary(ar);
> +       return CE_WRAPPER_INTERRUPT_SUMMARY_HOST_MSI_GET(
> +               ce->bus_ops->read32((ar), CE_WRAPPER_BASE_ADDRESS +
> +               CE_WRAPPER_INTERRUPT_SUMMARY_ADDRESS));
>  }
>
>  /* Host software's Copy Engine configuration. */

> diff --git a/drivers/net/wireless/ath/ath10k/snoc.h b/drivers/net/wireless/ath/ath10k/snoc.h
> index a3dd06f6ac62..5095d1893681 100644
> --- a/drivers/net/wireless/ath/ath10k/snoc.h
> +++ b/drivers/net/wireless/ath/ath10k/snoc.h
> @@ -78,6 +78,7 @@ struct ath10k_snoc {
>         unsigned long flags;
>         bool xo_cal_supported;
>         u32 xo_cal_data;
> +       DECLARE_BITMAP(pending_ce_irqs, CE_COUNT_MAX);

Do you need to clear this map if the interface goes down or if there's
a firmware crash? Right now, I don't think there's a guarantee that
we'll run through a NAPI poll in those cases, which is the only place
you clear the map, and if the hardware/firmware has been reset, the
state map is probably not valid.

Otherwise, looks OK to me:

Reviewed-by: Brian Norris <briannorris at chromium.org>


From dianders at chromium.org  Wed Jul  8 19:14:18 2020
From: dianders at chromium.org (Doug Anderson)
Date: Wed, 8 Jul 2020 16:14:18 -0700
Subject: [PATCH] ath10k: Keep track of which interrupts fired,
 don't poll them
In-Reply-To: <CA+ASDXMXtwdV4BNL1GSj8DY-3z8-dZ=1hP8Xv_R-AjKvJs0NMw@mail.gmail.com>
References: <20200707101712.1.I4d2f85ffa06f38532631e864a3125691ef5ffe06@changeid>
 <CA+ASDXMXtwdV4BNL1GSj8DY-3z8-dZ=1hP8Xv_R-AjKvJs0NMw@mail.gmail.com>
Message-ID: <CAD=FV=WU2dUFtG4W6o574DRN9VV+u_B5-ThqV3BogjztBibyLQ@mail.gmail.com>

Hi,

On Wed, Jul 8, 2020 at 4:03 PM Brian Norris <briannorris at chromium.org> wrote:
>
> On Tue, Jul 7, 2020 at 10:18 AM Douglas Anderson <dianders at chromium.org> wrote:
> > diff --git a/drivers/net/wireless/ath/ath10k/ce.h b/drivers/net/wireless/ath/ath10k/ce.h
> > index a440aaf74aa4..666ce384a1d8 100644
> > --- a/drivers/net/wireless/ath/ath10k/ce.h
> > +++ b/drivers/net/wireless/ath/ath10k/ce.h
> ...
> > @@ -376,12 +377,9 @@ static inline u32 ath10k_ce_interrupt_summary(struct ath10k *ar)
> >  {
> >         struct ath10k_ce *ce = ath10k_ce_priv(ar);
> >
> > -       if (!ar->hw_params.per_ce_irq)
>
> If I'm reading correctly, you're removing the only remaining use of
> 'per_ce_irq'. Should we kill the field entirely?

Ah, you are indeed correct!  I hadn't noticed that.  Unless I hear
otherwise, I'll send a v2 tomorrow that removes the field entirely.


> Or perhaps we should
> leave some kind of WARN_ON() (BUG_ON()?) if this function is called
> erroneously with per_ce_irq==true? But I suppose this driver is full
> of landmines if the CE API is used incorrectly.

Yeah, I originally had a WARN_ON() here and then took it out because
it seemed like extra overhead and, as you said, someone writing the
code has to know how the API works already I think.  ...but I'll add
it back in if people want.


> > -               return CE_WRAPPER_INTERRUPT_SUMMARY_HOST_MSI_GET(
> > -                       ce->bus_ops->read32((ar), CE_WRAPPER_BASE_ADDRESS +
> > -                       CE_WRAPPER_INTERRUPT_SUMMARY_ADDRESS));
> > -       else
> > -               return ath10k_ce_gen_interrupt_summary(ar);
> > +       return CE_WRAPPER_INTERRUPT_SUMMARY_HOST_MSI_GET(
> > +               ce->bus_ops->read32((ar), CE_WRAPPER_BASE_ADDRESS +
> > +               CE_WRAPPER_INTERRUPT_SUMMARY_ADDRESS));
> >  }
> >
> >  /* Host software's Copy Engine configuration. */
>
> > diff --git a/drivers/net/wireless/ath/ath10k/snoc.h b/drivers/net/wireless/ath/ath10k/snoc.h
> > index a3dd06f6ac62..5095d1893681 100644
> > --- a/drivers/net/wireless/ath/ath10k/snoc.h
> > +++ b/drivers/net/wireless/ath/ath10k/snoc.h
> > @@ -78,6 +78,7 @@ struct ath10k_snoc {
> >         unsigned long flags;
> >         bool xo_cal_supported;
> >         u32 xo_cal_data;
> > +       DECLARE_BITMAP(pending_ce_irqs, CE_COUNT_MAX);
>
> Do you need to clear this map if the interface goes down or if there's
> a firmware crash? Right now, I don't think there's a guarantee that
> we'll run through a NAPI poll in those cases, which is the only place
> you clear the map, and if the hardware/firmware has been reset, the
> state map is probably not valid.

Seems like a good idea.  Is the right place at the start of
ath10k_snoc_hif_start()?


> Otherwise, looks OK to me:
>
> Reviewed-by: Brian Norris <briannorris at chromium.org>

Thanks for the review!

-Doug


From briannorris at chromium.org  Wed Jul  8 19:39:47 2020
From: briannorris at chromium.org (Brian Norris)
Date: Wed, 8 Jul 2020 16:39:47 -0700
Subject: [PATCH] ath10k: Keep track of which interrupts fired,
 don't poll them
In-Reply-To: <CAD=FV=WU2dUFtG4W6o574DRN9VV+u_B5-ThqV3BogjztBibyLQ@mail.gmail.com>
References: <20200707101712.1.I4d2f85ffa06f38532631e864a3125691ef5ffe06@changeid>
 <CA+ASDXMXtwdV4BNL1GSj8DY-3z8-dZ=1hP8Xv_R-AjKvJs0NMw@mail.gmail.com>
 <CAD=FV=WU2dUFtG4W6o574DRN9VV+u_B5-ThqV3BogjztBibyLQ@mail.gmail.com>
Message-ID: <CA+ASDXOwFnCcMC9g11FSVLvj2nepArJyihGvx3SU-XqySoJruw@mail.gmail.com>

On Wed, Jul 8, 2020 at 4:14 PM Doug Anderson <dianders at chromium.org> wrote:
> On Wed, Jul 8, 2020 at 4:03 PM Brian Norris <briannorris at chromium.org> wrote:
> > If I'm reading correctly, you're removing the only remaining use of
> > 'per_ce_irq'. Should we kill the field entirely?
>
> Ah, you are indeed correct!  I hadn't noticed that.  Unless I hear
> otherwise, I'll send a v2 tomorrow that removes the field entirely.

A healthy middle ground might put that in a patch 2, so it's easily
dropped if desired. *shrug*

> > Or perhaps we should
> > leave some kind of WARN_ON() (BUG_ON()?) if this function is called
> > erroneously with per_ce_irq==true? But I suppose this driver is full
> > of landmines if the CE API is used incorrectly.
>
> Yeah, I originally had a WARN_ON() here and then took it out because
> it seemed like extra overhead and, as you said, someone writing the
> code has to know how the API works already I think.  ...but I'll add
> it back in if people want.

I believe WARN_ON() and friends have a built-in unlikely(), so it
shouldn't have much overhead. But I don't really mind either way.

> > Do you need to clear this map if the interface goes down or if there's
> > a firmware crash? Right now, I don't think there's a guarantee that
> > we'll run through a NAPI poll in those cases, which is the only place
> > you clear the map, and if the hardware/firmware has been reset, the
> > state map is probably not valid.
>
> Seems like a good idea.  Is the right place at the start of
> ath10k_snoc_hif_start()?

Either there or in .power_down()/.power_up(). I think either would be
equally correct, but I'm not entirely sure if the semantic difference
is meaningful for this.

Brian


From dianders at chromium.org  Thu Jul  9 11:21:04 2020
From: dianders at chromium.org (Douglas Anderson)
Date: Thu,  9 Jul 2020 08:21:04 -0700
Subject: [PATCH v2 1/2] ath10k: Keep track of which interrupts fired,
 don't poll them
Message-ID: <20200709082024.v2.1.I4d2f85ffa06f38532631e864a3125691ef5ffe06@changeid>

If we have a per CE (Copy Engine) IRQ then we have no summary
register.  Right now the code generates a summary register by
iterating over all copy engines and seeing if they have an interrupt
pending.

This has a problem.  Specifically if _none_ if the Copy Engines have
an interrupt pending then they might go into low power mode and
reading from their address space will cause a full system crash.  This
was seen to happen when two interrupts went off at nearly the same
time.  Both were handled by a single call of ath10k_snoc_napi_poll()
but, because there were two interrupts handled and thus two calls to
napi_schedule() there was still a second call to
ath10k_snoc_napi_poll() which ran with no interrupts pending.

Instead of iterating over all the copy engines, let's just keep track
of the IRQs that fire.  Then we can effectively generate our own
summary without ever needing to read the Copy Engines.

Tested-on: WCN3990 SNOC WLAN.HL.3.2.2-00490-QCAHLSWMTPL-1

Signed-off-by: Douglas Anderson <dianders at chromium.org>
Reviewed-by: Rakesh Pillai <pillair at codeaurora.org>
Reviewed-by: Brian Norris <briannorris at chromium.org>
---
This patch continues work to try to squash all instances of the crash
we've been seeing while reading CE registers and hopefully this patch
addresses the true root of the issue.

The first patch that attempted to address these problems landed as
commit 8f9ed93d09a9 ("ath10k: Wait until copy complete is actually
done before completing").  After that Rakesh Pillai posted ("ath10k:
Add interrupt summary based CE processing") [1] and this patch is
based atop that one.  Both of those patches significantly reduced the
instances of problems but didn't fully eliminate them.  Crossing my
fingers that they're all gone now.

[1] https://lore.kernel.org/r/1593193967-29897-1-git-send-email-pillair at codeaurora.org

Changes in v2:
- Add bitmap_clear() in ath10k_snoc_hif_start().

 drivers/net/wireless/ath/ath10k/ce.c   | 84 ++++++++++----------------
 drivers/net/wireless/ath/ath10k/ce.h   | 14 ++---
 drivers/net/wireless/ath/ath10k/snoc.c | 19 ++++--
 drivers/net/wireless/ath/ath10k/snoc.h |  1 +
 4 files changed, 52 insertions(+), 66 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/ce.c b/drivers/net/wireless/ath/ath10k/ce.c
index 1e16f263854a..84ec80c6d08f 100644
--- a/drivers/net/wireless/ath/ath10k/ce.c
+++ b/drivers/net/wireless/ath/ath10k/ce.c
@@ -481,38 +481,6 @@ static inline void ath10k_ce_engine_int_status_clear(struct ath10k *ar,
 	ath10k_ce_write32(ar, ce_ctrl_addr + wm_regs->addr, mask);
 }
 
-static bool ath10k_ce_engine_int_status_check(struct ath10k *ar, u32 ce_ctrl_addr,
-					      unsigned int mask)
-{
-	struct ath10k_hw_ce_host_wm_regs *wm_regs = ar->hw_ce_regs->wm_regs;
-
-	return ath10k_ce_read32(ar, ce_ctrl_addr + wm_regs->addr) & mask;
-}
-
-u32 ath10k_ce_gen_interrupt_summary(struct ath10k *ar)
-{
-	struct ath10k_hw_ce_host_wm_regs *wm_regs = ar->hw_ce_regs->wm_regs;
-	struct ath10k_ce_pipe *ce_state;
-	struct ath10k_ce *ce;
-	u32 irq_summary = 0;
-	u32 ctrl_addr;
-	u32 ce_id;
-
-	ce = ath10k_ce_priv(ar);
-
-	for (ce_id = 0; ce_id < CE_COUNT; ce_id++) {
-		ce_state = &ce->ce_states[ce_id];
-		ctrl_addr = ce_state->ctrl_addr;
-		if (ath10k_ce_engine_int_status_check(ar, ctrl_addr,
-						      wm_regs->cc_mask)) {
-			irq_summary |= BIT(ce_id);
-		}
-	}
-
-	return irq_summary;
-}
-EXPORT_SYMBOL(ath10k_ce_gen_interrupt_summary);
-
 /*
  * Guts of ath10k_ce_send.
  * The caller takes responsibility for any needed locking.
@@ -1399,45 +1367,55 @@ static void ath10k_ce_per_engine_handler_adjust(struct ath10k_ce_pipe *ce_state)
 	ath10k_ce_watermark_intr_disable(ar, ctrl_addr);
 }
 
-int ath10k_ce_disable_interrupts(struct ath10k *ar)
+void ath10k_ce_disable_interrupt(struct ath10k *ar, int ce_id)
 {
 	struct ath10k_ce *ce = ath10k_ce_priv(ar);
 	struct ath10k_ce_pipe *ce_state;
 	u32 ctrl_addr;
-	int ce_id;
 
-	for (ce_id = 0; ce_id < CE_COUNT; ce_id++) {
-		ce_state  = &ce->ce_states[ce_id];
-		if (ce_state->attr_flags & CE_ATTR_POLL)
-			continue;
+	ce_state  = &ce->ce_states[ce_id];
+	if (ce_state->attr_flags & CE_ATTR_POLL)
+		return;
 
-		ctrl_addr = ath10k_ce_base_address(ar, ce_id);
+	ctrl_addr = ath10k_ce_base_address(ar, ce_id);
 
-		ath10k_ce_copy_complete_intr_disable(ar, ctrl_addr);
-		ath10k_ce_error_intr_disable(ar, ctrl_addr);
-		ath10k_ce_watermark_intr_disable(ar, ctrl_addr);
-	}
+	ath10k_ce_copy_complete_intr_disable(ar, ctrl_addr);
+	ath10k_ce_error_intr_disable(ar, ctrl_addr);
+	ath10k_ce_watermark_intr_disable(ar, ctrl_addr);
+}
+EXPORT_SYMBOL(ath10k_ce_disable_interrupt);
 
-	return 0;
+void ath10k_ce_disable_interrupts(struct ath10k *ar)
+{
+	int ce_id;
+
+	for (ce_id = 0; ce_id < CE_COUNT; ce_id++)
+		ath10k_ce_disable_interrupt(ar, ce_id);
 }
 EXPORT_SYMBOL(ath10k_ce_disable_interrupts);
 
-void ath10k_ce_enable_interrupts(struct ath10k *ar)
+void ath10k_ce_enable_interrupt(struct ath10k *ar, int ce_id)
 {
 	struct ath10k_ce *ce = ath10k_ce_priv(ar);
-	int ce_id;
 	struct ath10k_ce_pipe *ce_state;
 
+	ce_state  = &ce->ce_states[ce_id];
+	if (ce_state->attr_flags & CE_ATTR_POLL)
+		return;
+
+	ath10k_ce_per_engine_handler_adjust(ce_state);
+}
+EXPORT_SYMBOL(ath10k_ce_enable_interrupt);
+
+void ath10k_ce_enable_interrupts(struct ath10k *ar)
+{
+	int ce_id;
+
 	/* Enable interrupts for copy engine that
 	 * are not using polling mode.
 	 */
-	for (ce_id = 0; ce_id < CE_COUNT; ce_id++) {
-		ce_state  = &ce->ce_states[ce_id];
-		if (ce_state->attr_flags & CE_ATTR_POLL)
-			continue;
-
-		ath10k_ce_per_engine_handler_adjust(ce_state);
-	}
+	for (ce_id = 0; ce_id < CE_COUNT; ce_id++)
+		ath10k_ce_enable_interrupt(ar, ce_id);
 }
 EXPORT_SYMBOL(ath10k_ce_enable_interrupts);
 
diff --git a/drivers/net/wireless/ath/ath10k/ce.h b/drivers/net/wireless/ath/ath10k/ce.h
index a440aaf74aa4..666ce384a1d8 100644
--- a/drivers/net/wireless/ath/ath10k/ce.h
+++ b/drivers/net/wireless/ath/ath10k/ce.h
@@ -255,12 +255,13 @@ int ath10k_ce_cancel_send_next(struct ath10k_ce_pipe *ce_state,
 /*==================CE Interrupt Handlers====================*/
 void ath10k_ce_per_engine_service_any(struct ath10k *ar);
 void ath10k_ce_per_engine_service(struct ath10k *ar, unsigned int ce_id);
-int ath10k_ce_disable_interrupts(struct ath10k *ar);
+void ath10k_ce_disable_interrupt(struct ath10k *ar, int ce_id);
+void ath10k_ce_disable_interrupts(struct ath10k *ar);
+void ath10k_ce_enable_interrupt(struct ath10k *ar, int ce_id);
 void ath10k_ce_enable_interrupts(struct ath10k *ar);
 void ath10k_ce_dump_registers(struct ath10k *ar,
 			      struct ath10k_fw_crash_data *crash_data);
 
-u32 ath10k_ce_gen_interrupt_summary(struct ath10k *ar);
 void ath10k_ce_alloc_rri(struct ath10k *ar);
 void ath10k_ce_free_rri(struct ath10k *ar);
 
@@ -376,12 +377,9 @@ static inline u32 ath10k_ce_interrupt_summary(struct ath10k *ar)
 {
 	struct ath10k_ce *ce = ath10k_ce_priv(ar);
 
-	if (!ar->hw_params.per_ce_irq)
-		return CE_WRAPPER_INTERRUPT_SUMMARY_HOST_MSI_GET(
-			ce->bus_ops->read32((ar), CE_WRAPPER_BASE_ADDRESS +
-			CE_WRAPPER_INTERRUPT_SUMMARY_ADDRESS));
-	else
-		return ath10k_ce_gen_interrupt_summary(ar);
+	return CE_WRAPPER_INTERRUPT_SUMMARY_HOST_MSI_GET(
+		ce->bus_ops->read32((ar), CE_WRAPPER_BASE_ADDRESS +
+		CE_WRAPPER_INTERRUPT_SUMMARY_ADDRESS));
 }
 
 /* Host software's Copy Engine configuration. */
diff --git a/drivers/net/wireless/ath/ath10k/snoc.c b/drivers/net/wireless/ath/ath10k/snoc.c
index 354d49b1cd45..1ef5fdb8248b 100644
--- a/drivers/net/wireless/ath/ath10k/snoc.c
+++ b/drivers/net/wireless/ath/ath10k/snoc.c
@@ -3,6 +3,7 @@
  * Copyright (c) 2018 The Linux Foundation. All rights reserved.
  */
 
+#include <linux/bits.h>
 #include <linux/clk.h>
 #include <linux/kernel.h>
 #include <linux/module.h>
@@ -923,6 +924,7 @@ static int ath10k_snoc_hif_start(struct ath10k *ar)
 {
 	struct ath10k_snoc *ar_snoc = ath10k_snoc_priv(ar);
 
+	bitmap_clear(ar_snoc->pending_ce_irqs, 0, CE_COUNT_MAX);
 	napi_enable(&ar->napi);
 	ath10k_snoc_irq_enable(ar);
 	ath10k_snoc_rx_post(ar);
@@ -1158,7 +1160,9 @@ static irqreturn_t ath10k_snoc_per_engine_handler(int irq, void *arg)
 		return IRQ_HANDLED;
 	}
 
-	ath10k_snoc_irq_disable(ar);
+	ath10k_ce_disable_interrupt(ar, ce_id);
+	set_bit(ce_id, ar_snoc->pending_ce_irqs);
+
 	napi_schedule(&ar->napi);
 
 	return IRQ_HANDLED;
@@ -1167,20 +1171,25 @@ static irqreturn_t ath10k_snoc_per_engine_handler(int irq, void *arg)
 static int ath10k_snoc_napi_poll(struct napi_struct *ctx, int budget)
 {
 	struct ath10k *ar = container_of(ctx, struct ath10k, napi);
+	struct ath10k_snoc *ar_snoc = ath10k_snoc_priv(ar);
 	int done = 0;
+	int ce_id;
 
 	if (test_bit(ATH10K_FLAG_CRASH_FLUSH, &ar->dev_flags)) {
 		napi_complete(ctx);
 		return done;
 	}
 
-	ath10k_ce_per_engine_service_any(ar);
+	for (ce_id = 0; ce_id < CE_COUNT; ce_id++)
+		if (test_and_clear_bit(ce_id, ar_snoc->pending_ce_irqs)) {
+			ath10k_ce_per_engine_service(ar, ce_id);
+			ath10k_ce_enable_interrupt(ar, ce_id);
+		}
+
 	done = ath10k_htt_txrx_compl_task(ar, budget);
 
-	if (done < budget) {
+	if (done < budget)
 		napi_complete(ctx);
-		ath10k_snoc_irq_enable(ar);
-	}
 
 	return done;
 }
diff --git a/drivers/net/wireless/ath/ath10k/snoc.h b/drivers/net/wireless/ath/ath10k/snoc.h
index a3dd06f6ac62..5095d1893681 100644
--- a/drivers/net/wireless/ath/ath10k/snoc.h
+++ b/drivers/net/wireless/ath/ath10k/snoc.h
@@ -78,6 +78,7 @@ struct ath10k_snoc {
 	unsigned long flags;
 	bool xo_cal_supported;
 	u32 xo_cal_data;
+	DECLARE_BITMAP(pending_ce_irqs, CE_COUNT_MAX);
 };
 
 static inline struct ath10k_snoc *ath10k_snoc_priv(struct ath10k *ar)
-- 
2.27.0.383.g050319c2ae-goog



From dianders at chromium.org  Thu Jul  9 11:21:05 2020
From: dianders at chromium.org (Douglas Anderson)
Date: Thu,  9 Jul 2020 08:21:05 -0700
Subject: [PATCH v2 2/2] ath10k: Get rid of "per_ce_irq" hw param
In-Reply-To: <20200709082024.v2.1.I4d2f85ffa06f38532631e864a3125691ef5ffe06@changeid>
References: <20200709082024.v2.1.I4d2f85ffa06f38532631e864a3125691ef5ffe06@changeid>
Message-ID: <20200709082024.v2.2.I083faa4e62e69f863311c89ae5eb28ec5a229b70@changeid>

As of the patch ("ath10k: Keep track of which interrupts fired, don't
poll them") we now have no users of this hardware parameter.  Remove
it.

Suggested-by: Brian Norris <briannorris at chromium.org>
Signed-off-by: Douglas Anderson <dianders at chromium.org>
---

Changes in v2:
- Patch ("ath10k: Get rid of "per_ce_irq" hw param") new for v2.

 drivers/net/wireless/ath/ath10k/core.c | 13 -------------
 drivers/net/wireless/ath/ath10k/hw.h   |  3 ---
 2 files changed, 16 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 22b6937ac225..9104496a5125 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -119,7 +119,6 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 		.num_wds_entries = 0x20,
 		.target_64bit = false,
 		.rx_ring_fill_level = HTT_RX_RING_FILL_LEVEL,
-		.per_ce_irq = false,
 		.shadow_reg_support = false,
 		.rri_on_ddr = false,
 		.hw_filter_reset_required = true,
@@ -155,7 +154,6 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 		.num_wds_entries = 0x20,
 		.target_64bit = false,
 		.rx_ring_fill_level = HTT_RX_RING_FILL_LEVEL,
-		.per_ce_irq = false,
 		.shadow_reg_support = false,
 		.rri_on_ddr = false,
 		.hw_filter_reset_required = true,
@@ -220,7 +218,6 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 		.num_wds_entries = 0x20,
 		.target_64bit = false,
 		.rx_ring_fill_level = HTT_RX_RING_FILL_LEVEL,
-		.per_ce_irq = false,
 		.shadow_reg_support = false,
 		.rri_on_ddr = false,
 		.hw_filter_reset_required = true,
@@ -255,7 +252,6 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 		.num_wds_entries = 0x20,
 		.target_64bit = false,
 		.rx_ring_fill_level = HTT_RX_RING_FILL_LEVEL,
-		.per_ce_irq = false,
 		.shadow_reg_support = false,
 		.rri_on_ddr = false,
 		.hw_filter_reset_required = true,
@@ -290,7 +286,6 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 		.num_wds_entries = 0x20,
 		.target_64bit = false,
 		.rx_ring_fill_level = HTT_RX_RING_FILL_LEVEL,
-		.per_ce_irq = false,
 		.shadow_reg_support = false,
 		.rri_on_ddr = false,
 		.hw_filter_reset_required = true,
@@ -328,7 +323,6 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 		.num_wds_entries = 0x20,
 		.target_64bit = false,
 		.rx_ring_fill_level = HTT_RX_RING_FILL_LEVEL,
-		.per_ce_irq = false,
 		.shadow_reg_support = false,
 		.rri_on_ddr = false,
 		.hw_filter_reset_required = true,
@@ -369,7 +363,6 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 		.num_wds_entries = 0x20,
 		.target_64bit = false,
 		.rx_ring_fill_level = HTT_RX_RING_FILL_LEVEL,
-		.per_ce_irq = false,
 		.shadow_reg_support = false,
 		.rri_on_ddr = false,
 		.hw_filter_reset_required = true,
@@ -417,7 +410,6 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 		.num_wds_entries = 0x20,
 		.target_64bit = false,
 		.rx_ring_fill_level = HTT_RX_RING_FILL_LEVEL,
-		.per_ce_irq = false,
 		.shadow_reg_support = false,
 		.rri_on_ddr = false,
 		.hw_filter_reset_required = true,
@@ -462,7 +454,6 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 		.num_wds_entries = 0x20,
 		.target_64bit = false,
 		.rx_ring_fill_level = HTT_RX_RING_FILL_LEVEL,
-		.per_ce_irq = false,
 		.shadow_reg_support = false,
 		.rri_on_ddr = false,
 		.hw_filter_reset_required = true,
@@ -497,7 +488,6 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 		.num_wds_entries = 0x20,
 		.target_64bit = false,
 		.rx_ring_fill_level = HTT_RX_RING_FILL_LEVEL,
-		.per_ce_irq = false,
 		.shadow_reg_support = false,
 		.rri_on_ddr = false,
 		.hw_filter_reset_required = true,
@@ -534,7 +524,6 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 		.num_wds_entries = 0x20,
 		.target_64bit = false,
 		.rx_ring_fill_level = HTT_RX_RING_FILL_LEVEL,
-		.per_ce_irq = false,
 		.shadow_reg_support = false,
 		.rri_on_ddr = false,
 		.hw_filter_reset_required = true,
@@ -603,7 +592,6 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 		.num_wds_entries = 0x20,
 		.target_64bit = false,
 		.rx_ring_fill_level = HTT_RX_RING_FILL_LEVEL,
-		.per_ce_irq = false,
 		.shadow_reg_support = false,
 		.rri_on_ddr = false,
 		.hw_filter_reset_required = true,
@@ -631,7 +619,6 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 		.num_wds_entries = TARGET_HL_TLV_NUM_WDS_ENTRIES,
 		.target_64bit = true,
 		.rx_ring_fill_level = HTT_RX_RING_FILL_LEVEL_DUAL_MAC,
-		.per_ce_irq = true,
 		.shadow_reg_support = true,
 		.rri_on_ddr = true,
 		.hw_filter_reset_required = false,
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index f16edcb9f326..c6ded21f5ed6 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -593,9 +593,6 @@ struct ath10k_hw_params {
 	/* Target rx ring fill level */
 	u32 rx_ring_fill_level;
 
-	/* target supporting per ce IRQ */
-	bool per_ce_irq;
-
 	/* target supporting shadow register for ce write */
 	bool shadow_reg_support;
 
-- 
2.27.0.383.g050319c2ae-goog



From dianders at chromium.org  Thu Jul  9 11:22:28 2020
From: dianders at chromium.org (Doug Anderson)
Date: Thu, 9 Jul 2020 08:22:28 -0700
Subject: [PATCH] ath10k: Keep track of which interrupts fired,
 don't poll them
In-Reply-To: <CA+ASDXOwFnCcMC9g11FSVLvj2nepArJyihGvx3SU-XqySoJruw@mail.gmail.com>
References: <20200707101712.1.I4d2f85ffa06f38532631e864a3125691ef5ffe06@changeid>
 <CA+ASDXMXtwdV4BNL1GSj8DY-3z8-dZ=1hP8Xv_R-AjKvJs0NMw@mail.gmail.com>
 <CAD=FV=WU2dUFtG4W6o574DRN9VV+u_B5-ThqV3BogjztBibyLQ@mail.gmail.com>
 <CA+ASDXOwFnCcMC9g11FSVLvj2nepArJyihGvx3SU-XqySoJruw@mail.gmail.com>
Message-ID: <CAD=FV=WUpHGoLm+NG-_eGsVKO7X+SLObFCoQVBSCNEa6KRmpmA@mail.gmail.com>

Hi,

On Wed, Jul 8, 2020 at 4:40 PM Brian Norris <briannorris at chromium.org> wrote:
>
> On Wed, Jul 8, 2020 at 4:14 PM Doug Anderson <dianders at chromium.org> wrote:
> > On Wed, Jul 8, 2020 at 4:03 PM Brian Norris <briannorris at chromium.org> wrote:
> > > If I'm reading correctly, you're removing the only remaining use of
> > > 'per_ce_irq'. Should we kill the field entirely?
> >
> > Ah, you are indeed correct!  I hadn't noticed that.  Unless I hear
> > otherwise, I'll send a v2 tomorrow that removes the field entirely.
>
> A healthy middle ground might put that in a patch 2, so it's easily
> dropped if desired. *shrug*

Sure, sounds like a plan.


> > > Or perhaps we should
> > > leave some kind of WARN_ON() (BUG_ON()?) if this function is called
> > > erroneously with per_ce_irq==true? But I suppose this driver is full
> > > of landmines if the CE API is used incorrectly.
> >
> > Yeah, I originally had a WARN_ON() here and then took it out because
> > it seemed like extra overhead and, as you said, someone writing the
> > code has to know how the API works already I think.  ...but I'll add
> > it back in if people want.
>
> I believe WARN_ON() and friends have a built-in unlikely(), so it
> shouldn't have much overhead. But I don't really mind either way.

Since you don't feel strongly, leaving it off.


> > > Do you need to clear this map if the interface goes down or if there's
> > > a firmware crash? Right now, I don't think there's a guarantee that
> > > we'll run through a NAPI poll in those cases, which is the only place
> > > you clear the map, and if the hardware/firmware has been reset, the
> > > state map is probably not valid.
> >
> > Seems like a good idea.  Is the right place at the start of
> > ath10k_snoc_hif_start()?
>
> Either there or in .power_down()/.power_up(). I think either would be
> equally correct, but I'm not entirely sure if the semantic difference
> is meaningful for this.

Will choose ath10k_snoc_hif_start() since it's where napi_enable() is
and ath10k_snoc_irq_enable() are and those are related.


-Doug


From dev at zpc.sakura.ne.jp  Sat Jul 11 05:35:34 2020
From: dev at zpc.sakura.ne.jp (Yanase Yuki)
Date: Sat, 11 Jul 2020 18:35:34 +0900
Subject: ath10k-firmware: QCA9984 hw1.0: Add NEC Platforms WG2600HP3 specific
 BDFs
Message-ID: <20200711093201.GA1053@dev-email>

Hi.

These files are NEC Platforms WG2600HP3 specific BDFs extracted
from stock firmware.

Required information:

* description for what hardware this is:
  - it is a IPQ8062 based board
    - one QCA9984 radio is used as 2.4GHz radio
    - one QCA9984 radio is used as 5GHz radio

* origin of the board files
  - extracted from stock firmware

* ids to be used with the board files
  - bus=pci,bmi-chip-id=0,bmi-board-id=3,variant=NEC-Platforms-WG2600HP3
    - md5sum: c2cca25e45ba07320ecf4a4b16b9a9bc
    - sha1sum: 0a8f6701fc4654efe67bd3af897a77208c0434c7
  - bus=pci,bmi-chip-id=0,bmi-board-id=4,variant=NEC-Platforms-WG2600HP3
    - md5sum: a552038db2da69a9e91e38e607cceb56
    - sha1sum: de70d1dba9bb40c96ca1c26d85f839d024867a83

Best Regards.
Yanase Yuki
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bus=pci,bmi-chip-id=0,bmi-board-id=3,variant=NEC-Platforms-WG2600HP3.bin
Type: application/octet-stream
Size: 12064 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/ath10k/attachments/20200711/3f7df1ac/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bus=pci,bmi-chip-id=0,bmi-board-id=4,variant=NEC-Platforms-WG2600HP3.bin
Type: application/octet-stream
Size: 12064 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/ath10k/attachments/20200711/3f7df1ac/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/ath10k/attachments/20200711/3f7df1ac/attachment-0001.sig>

From radu.gabrielc at gmail.com  Tue Jul  7 14:11:54 2020
From: radu.gabrielc at gmail.com (Radu Coriu)
Date: Tue, 7 Jul 2020 21:11:54 +0300
Subject: Submitting just a board file
Message-ID: <CAFtP87veJYOQa-x-6Ry03pSeJaRispkb8X3eTav4muWniuvVJA@mail.gmail.com>

Hi,

I was reading this wiki page
(https://wireless.wiki.kernel.org/en/users/drivers/ath10k/boardfiles)
and wanted to submit a board-2.bin and firmware-5.bin received from
Compex support for the WLE1200VX board. The latest board-2.bin doesn't
seem to contain the board data for this board.
Could you please tell me how to extract the image data from the bin? I
am not familiar at all with ath10k.
I sent you the zip they sent me. Maybe it's useful for you. It also
contains a patch.

--


Regards,
Radu Coriu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Latest_wle1216vx-ath10k-ct-support.zip
Type: application/x-zip-compressed
Size: 486304 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/ath10k/attachments/20200707/2dd4d946/attachment-0001.bin>

From hauke at hauke-m.de  Tue Jul 14 16:58:02 2020
From: hauke at hauke-m.de (Hauke Mehrtens)
Date: Tue, 14 Jul 2020 22:58:02 +0200
Subject: [PATCH v5.8] ath10k: Fix NULL pointer dereference in AHB device probe
Message-ID: <20200714205802.17688-1-hauke@hauke-m.de>

This fixes a NULL pointer dereference in the probe path for AHB devices.
There attr parameter in the ath10k_ce_alloc_pipe() function is not
initialized, but accessed. This function is called by
ath10k_pci_setup_resource() which is called by ath10k_ahb_probe().

The struct ath10k_pci is also used for AHB devices and not only for PCI
devices.

The initialization of the new members of struct ath10k_pci is moved to
ath10k_pci_setup_resource() which is used by the PCI and the AHB code.

This also fixes a use after free bug in ath10k_pci_remove() when ar_pci
is accessed after ath10k_core_destroy() was called, which calls
ieee80211_free_hw() and frees this memory.

This fixes the following bug seen with backports-5.8-rc2 on OpenWrt on a
IPQ4019 device:

[   11.117462] 8<--- cut here ---
[   11.117494] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[   11.119510] pgd = f377fd58
[   11.127657] [00000000] *pgd=8e9a0835, *pte=00000000, *ppte=00000000
[   11.130206] Internal error: Oops: 17 [#1] SMP ARM
[   11.136339] Modules linked in: ath10k_pci(+) ath10k_core ath xt_state xt_nat xt_conntrack xt_REDIRECT xt_MASQUERADE xt_FLOWOFFLOAD pppox ppp_generic nf_nat nf_flow_table_hw nf_flow_table nf_conntrack_rtcache nf_conntrack mac80211 ipt_REJECT cfg80211 xt_time xt_tcpudp xt_multiport xt_mark xt_mac xt_limit xt_comment xt_TCPMSS xt_LOG slhc nf_reject_ipv4 nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 iptable_mangle iptable_filter ip_tables crc_ccitt compat nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 leds_gpio xhci_plat_hcd xhci_pci xhci_hcd dwc3 dwc3_qcom gpio_button_hotplug
[   11.174355] CPU: 2 PID: 257 Comm: kmodloader Not tainted 5.4.51 #0
[   11.196585] Hardware name: Generic DT based system
[   11.202746] PC is at ath10k_ce_alloc_pipe+0x58/0x180 [ath10k_core]
[   11.207459] LR is at ath10k_pci_alloc_pipes+0x94/0xc8 [ath10k_pci]
[   11.213600] pc : [<bf2c96cc>]    lr : [<bf2fbf98>]    psr: 80000013
[   11.219760] sp : cea0dc90  ip : cf4001f0  fp : 00000001
[   11.225923] r10: 00000000  r9 : 00000018  r8 : ce4963b4
[   11.231133] r7 : 00000000  r6 : ce491ea0  r5 : 00000000  r4 : ce4963b4
[   11.236342] r3 : 0004a000  r2 : 0004a000  r1 : bf2d0d70  r0 : 00000006
[   11.242942] Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[   11.249452] Control: 10c5387d  Table: 8e9c006a  DAC: 00000051
[   11.256656] Process kmodloader (pid: 257, stack limit = 0xaba286ca)
[   11.262386] Stack: (0xcea0dc90 to 0xcea0e000)
[   11.268462] dc80:                                     00000000 ce49629c ce491ea0 ce4963bc
[   11.272984] dca0: ce495ea0 bf2fbf98 00000002 ce4963a8 ce495ea0 00000000 ce491ea0 cf95d800
[   11.281142] dcc0: cf95d810 cf95d810 00000001 bf2fc854 00000000 cf95d800 bf300748 ce495ea0
[   11.289304] dce0: ce491ea0 d1300000 cf95d800 bf2fde8c 00000000 00000001 ce49cea0 00000000
[   11.297462] dd00: 00000000 00000000 bf3010a0 cf95d810 bf3010a0 c0b61580 00000000 00000000
[   11.305624] dd20: bf3010a0 0000000b c0b04e48 c06110c8 c0b61588 cf95d810 c0b61580 c060f740
[   11.313781] dd40: cf95d810 00000000 bf3010a0 00000000 00000000 ce49d2a4 bf301100 c060fc90
[   11.321943] dd60: 00000000 bf3010a0 cf95d810 c060fcf0 cf95d810 bf3010a0 c060fc98 c060dca4
[   11.330101] dd80: cf809d58 cf952cb4 bf3010a0 ce967900 c0b1f2c8 c060ec28 bf3007b8 bf301038
[   11.338263] dda0: bf3010a0 bf3010a0 c0b2d4d4 ffffe000 bf304000 c0610278 c0b04e48 c0b2d4d4
[   11.346422] ddc0: ffffe000 bf2fe2b4 c0b04e48 bf30403c c0b04e48 c0302764 8040003f 00000001
[   11.354582] dde0: 38e38e39 ce513580 c0b2cb50 cf801e00 cffbc6ac ce513600 cf801e00 cffbc6ac
[   11.362740] de00: 8040003e ce49d280 00000001 c0428d54 00000001 cf801e00 cffbc6ac ce513580
[   11.370900] de20: ce49d280 0e391998 bf301100 ce49d340 d12d2000 ce49d280 00000001 c0398c2c
[   11.379061] de40: 00000001 cea0df34 cea0df34 00000001 d12d2000 c039ae48 bf30110c 00007fff
[   11.387221] de60: bf301100 c0398044 cf804028 bf301148 c0397674 bf30126c c08ee5c0 c08ee70c
[   11.395380] de80: bf30110c c0b04e48 c08ee518 00000000 c08ee570 c0b04e48 ce513600 fffff000
[   11.403540] dea0: 00000001 ce513580 0000000d 0000000d 00000000 00000000 00000000 00000000
[   11.411698] dec0: 00000000 00000000 6e72656b 00006c65 00000000 00000000 00000000 00000000
[   11.419858] dee0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[   11.428018] df00: 00000000 0e391998 00000000 0000c610 d12de610 00000000 0062c620 ffffe000
[   11.436180] df20: 000129d1 00000051 00000000 c039b228 00000000 d12d7afd d12d8e80 d12d2000
[   11.444337] df40: 0000c610 d12de0e8 d12ddfa8 d12dab74 00009000 00009570 00003a2c 00009cae
[   11.452498] df60: 00000000 00000000 00000000 00003a1c 0000001e 0000001f 00000018 00000000
[   11.460656] df80: 00000010 00000000 00000000 00000000 00000003 00000080 c0301204 cea0c000
[   11.468817] dfa0: 00000080 c0301000 00000000 00000000 00620010 0000c610 000129d1 00000014
[   11.476975] dfc0: 00000000 00000000 00000003 00000080 0000c610 00000000 b6fc1d20 00000000
[   11.485137] dfe0: bef0ad14 bef0acf8 00011e14 b6f74c94 60000010 00620010 00000000 00000000
[   11.493390] [<bf2c96cc>] (ath10k_ce_alloc_pipe [ath10k_core]) from [<bf2fbf98>] (ath10k_pci_alloc_pipes+0x94/0xc8 [ath10k_pci])
[   11.501498] [<bf2fbf98>] (ath10k_pci_alloc_pipes [ath10k_pci]) from [<bf2fc854>] (ath10k_pci_setup_resource+0xb8/0xf0 [ath10k_pci])
[   11.512773] [<bf2fc854>] (ath10k_pci_setup_resource [ath10k_pci]) from [<bf2fde8c>] (ath10k_ahb_probe+0x32c/0x670 [ath10k_pci])
[   11.524566] [<bf2fde8c>] (ath10k_ahb_probe [ath10k_pci]) from [<c06110c8>] (platform_drv_probe+0x34/0x70)
[   11.536016] [<c06110c8>] (platform_drv_probe) from [<c060f740>] (really_probe+0x1f0/0x358)
[   11.545729] [<c060f740>] (really_probe) from [<c060fc90>] (device_driver_attach+0x58/0x60)
[   11.553886] [<c060fc90>] (device_driver_attach) from [<c060fcf0>] (__driver_attach+0x58/0xcc)
[   11.562134] [<c060fcf0>] (__driver_attach) from [<c060dca4>] (bus_for_each_dev+0x68/0x8c)
[   11.570731] [<c060dca4>] (bus_for_each_dev) from [<c060ec28>] (bus_add_driver+0x1c8/0x1d8)
[   11.578886] [<c060ec28>] (bus_add_driver) from [<c0610278>] (driver_register+0x74/0x108)
[   11.587060] [<c0610278>] (driver_register) from [<bf2fe2b4>] (ath10k_ahb_init+0x18/0x38 [ath10k_pci])
[   11.595320] [<bf2fe2b4>] (ath10k_ahb_init [ath10k_pci]) from [<bf30403c>] (init_module+0x3c/0x1000 [ath10k_pci])
[   11.604432] [<bf30403c>] (init_module [ath10k_pci]) from [<c0302764>] (do_one_initcall+0x84/0x1d8)
[   11.614657] [<c0302764>] (do_one_initcall) from [<c0398c2c>] (do_init_module+0x5c/0x228)
[   11.623421] [<c0398c2c>] (do_init_module) from [<c039ae48>] (load_module+0x1fc8/0x224c)
[   11.631663] [<c039ae48>] (load_module) from [<c039b228>] (sys_init_module+0x15c/0x17c)
[   11.639390] [<c039b228>] (sys_init_module) from [<c0301000>] (ret_fast_syscall+0x0/0x54)
[   11.647370] Exception stack(0xcea0dfa8 to 0xcea0dff0)
[   11.655615] dfa0:                   00000000 00000000 00620010 0000c610 000129d1 00000014
[   11.660569] dfc0: 00000000 00000000 00000003 00000080 0000c610 00000000 b6fc1d20 00000000
[   11.668725] dfe0: bef0ad14 bef0acf8 00011e14 b6f74c94
[   11.676886] Code: e1c321d4 e0433002 e0232397 e5843014 (e5953000)
[   11.681958] ---[ end trace 8f35917de2e76854 ]---

Fixes: 521fc37be3d8 ("ath10k: Avoid override CE5 configuration for QCA99X0 chipsets")
Reported-by: Stefan Lippers-Hollmann <s.l-h at gmx.de> [ipq40xx/ map-ac2200]
Signed-off-by: Hauke Mehrtens <hauke at hauke-m.de>
---
 drivers/net/wireless/ath/ath10k/ahb.c |  2 +-
 drivers/net/wireless/ath/ath10k/pci.c | 78 +++++++++++++--------------
 2 files changed, 38 insertions(+), 42 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/ahb.c b/drivers/net/wireless/ath/ath10k/ahb.c
index 342a7e58018a..05a61975c83f 100644
--- a/drivers/net/wireless/ath/ath10k/ahb.c
+++ b/drivers/net/wireless/ath/ath10k/ahb.c
@@ -820,7 +820,7 @@ static int ath10k_ahb_probe(struct platform_device *pdev)
 	ath10k_ahb_release_irq_legacy(ar);
 
 err_free_pipes:
-	ath10k_pci_free_pipes(ar);
+	ath10k_pci_release_resource(ar);
 
 err_resource_deinit:
 	ath10k_ahb_resource_deinit(ar);
diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index 1d941d53fdc9..cfde7791291a 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -3473,6 +3473,28 @@ int ath10k_pci_setup_resource(struct ath10k *ar)
 
 	timer_setup(&ar_pci->rx_post_retry, ath10k_pci_rx_replenish_retry, 0);
 
+	ar_pci->attr = kmemdup(pci_host_ce_config_wlan,
+			       sizeof(pci_host_ce_config_wlan),
+			       GFP_KERNEL);
+	if (!ar_pci->attr)
+		return -ENOMEM;
+
+	ar_pci->pipe_config = kmemdup(pci_target_ce_config_wlan,
+				      sizeof(pci_target_ce_config_wlan),
+				      GFP_KERNEL);
+	if (!ar_pci->pipe_config) {
+		ret = -ENOMEM;
+		goto err_free_attr;
+	}
+
+	ar_pci->serv_to_pipe = kmemdup(pci_target_service_to_ce_map_wlan,
+				       sizeof(pci_target_service_to_ce_map_wlan),
+				       GFP_KERNEL);
+	if (!ar_pci->serv_to_pipe) {
+		ret = -ENOMEM;
+		goto err_free_pipe_config;
+	}
+
 	if (QCA_REV_6174(ar) || QCA_REV_9377(ar))
 		ath10k_pci_override_ce_config(ar);
 
@@ -3480,18 +3502,31 @@ int ath10k_pci_setup_resource(struct ath10k *ar)
 	if (ret) {
 		ath10k_err(ar, "failed to allocate copy engine pipes: %d\n",
 			   ret);
-		return ret;
+		goto err_free_serv_to_pipe;
 	}
 
 	return 0;
+
+err_free_serv_to_pipe:
+	kfree(ar_pci->serv_to_pipe);
+err_free_pipe_config:
+	kfree(ar_pci->pipe_config);
+err_free_attr:
+	kfree(ar_pci->attr);
+	return ret;
 }
 
 void ath10k_pci_release_resource(struct ath10k *ar)
 {
+	struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
+
 	ath10k_pci_rx_retry_sync(ar);
 	netif_napi_del(&ar->napi);
 	ath10k_pci_ce_deinit(ar);
 	ath10k_pci_free_pipes(ar);
+	kfree(ar_pci->attr);
+	kfree(ar_pci->pipe_config);
+	kfree(ar_pci->serv_to_pipe);
 }
 
 static const struct ath10k_bus_ops ath10k_pci_bus_ops = {
@@ -3601,30 +3636,6 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
 
 	timer_setup(&ar_pci->ps_timer, ath10k_pci_ps_timer, 0);
 
-	ar_pci->attr = kmemdup(pci_host_ce_config_wlan,
-			       sizeof(pci_host_ce_config_wlan),
-			       GFP_KERNEL);
-	if (!ar_pci->attr) {
-		ret = -ENOMEM;
-		goto err_free;
-	}
-
-	ar_pci->pipe_config = kmemdup(pci_target_ce_config_wlan,
-				      sizeof(pci_target_ce_config_wlan),
-				      GFP_KERNEL);
-	if (!ar_pci->pipe_config) {
-		ret = -ENOMEM;
-		goto err_free;
-	}
-
-	ar_pci->serv_to_pipe = kmemdup(pci_target_service_to_ce_map_wlan,
-				       sizeof(pci_target_service_to_ce_map_wlan),
-				       GFP_KERNEL);
-	if (!ar_pci->serv_to_pipe) {
-		ret = -ENOMEM;
-		goto err_free;
-	}
-
 	ret = ath10k_pci_setup_resource(ar);
 	if (ret) {
 		ath10k_err(ar, "failed to setup resource: %d\n", ret);
@@ -3705,10 +3716,9 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
 
 err_free_irq:
 	ath10k_pci_free_irq(ar);
-	ath10k_pci_rx_retry_sync(ar);
 
 err_deinit_irq:
-	ath10k_pci_deinit_irq(ar);
+	ath10k_pci_release_resource(ar);
 
 err_sleep:
 	ath10k_pci_sleep_sync(ar);
@@ -3720,29 +3730,18 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
 err_core_destroy:
 	ath10k_core_destroy(ar);
 
-err_free:
-	kfree(ar_pci->attr);
-	kfree(ar_pci->pipe_config);
-	kfree(ar_pci->serv_to_pipe);
-
 	return ret;
 }
 
 static void ath10k_pci_remove(struct pci_dev *pdev)
 {
 	struct ath10k *ar = pci_get_drvdata(pdev);
-	struct ath10k_pci *ar_pci;
 
 	ath10k_dbg(ar, ATH10K_DBG_PCI, "pci remove\n");
 
 	if (!ar)
 		return;
 
-	ar_pci = ath10k_pci_priv(ar);
-
-	if (!ar_pci)
-		return;
-
 	ath10k_core_unregister(ar);
 	ath10k_pci_free_irq(ar);
 	ath10k_pci_deinit_irq(ar);
@@ -3750,9 +3749,6 @@ static void ath10k_pci_remove(struct pci_dev *pdev)
 	ath10k_pci_sleep_sync(ar);
 	ath10k_pci_release(ar);
 	ath10k_core_destroy(ar);
-	kfree(ar_pci->attr);
-	kfree(ar_pci->pipe_config);
-	kfree(ar_pci->serv_to_pipe);
 }
 
 MODULE_DEVICE_TABLE(pci, ath10k_pci_id_table);
-- 
2.20.1



From rmanohar at codeaurora.org  Tue Jul 14 22:20:22 2020
From: rmanohar at codeaurora.org (Rajkumar Manoharan)
Date: Tue, 14 Jul 2020 19:20:22 -0700
Subject: [PATCH v5.8] ath10k: Fix NULL pointer dereference in AHB device
 probe
In-Reply-To: <20200714205802.17688-1-hauke@hauke-m.de>
References: <20200714205802.17688-1-hauke@hauke-m.de>
Message-ID: <03aa088e5d2b46f570372f72c430f93f@codeaurora.org>

On 2020-07-14 13:58, Hauke Mehrtens wrote:
> This fixes a NULL pointer dereference in the probe path for AHB 
> devices.
> There attr parameter in the ath10k_ce_alloc_pipe() function is not
> initialized, but accessed. This function is called by
> ath10k_pci_setup_resource() which is called by ath10k_ahb_probe().
> 
> The struct ath10k_pci is also used for AHB devices and not only for PCI
> devices.
> 
> The initialization of the new members of struct ath10k_pci is moved to
> ath10k_pci_setup_resource() which is used by the PCI and the AHB code.
> 
> This also fixes a use after free bug in ath10k_pci_remove() when ar_pci
> is accessed after ath10k_core_destroy() was called, which calls
> ieee80211_free_hw() and frees this memory.
> 
> This fixes the following bug seen with backports-5.8-rc2 on OpenWrt on 
> a
> IPQ4019 device:
> 
Thanks Hauke for taking care of this. Your change LGTM.

-Rajkumar


From kvalo at codeaurora.org  Wed Jul 15 06:22:09 2020
From: kvalo at codeaurora.org (Kalle Valo)
Date: Wed, 15 Jul 2020 10:22:09 +0000 (UTC)
Subject: [PATCH 05/17] drivers: net: Fix trivial spelling
In-Reply-To: <20200609124610.3445662-6-kieran.bingham+renesas@ideasonboard.com>
References: <20200609124610.3445662-6-kieran.bingham+renesas@ideasonboard.com>
Message-ID: <20200715102209.BDB2AC43391@smtp.codeaurora.org>

Kieran Bingham <kieran.bingham+renesas at ideasonboard.com> wrote:

> The word 'descriptor' is misspelled throughout the tree.
> 
> Fix it up accordingly:
>     decriptors -> descriptors
> 
> Signed-off-by: Kieran Bingham <kieran.bingham+renesas at ideasonboard.com>

I recommend splitting wan and wireless changes to separate patches as I
cannot take changes to wan subsystem.

Patch set to Changes Requested.

-- 
https://patchwork.kernel.org/patch/11595487/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches



From kieran.bingham+renesas at ideasonboard.com  Wed Jul 15 08:48:31 2020
From: kieran.bingham+renesas at ideasonboard.com (Kieran Bingham)
Date: Wed, 15 Jul 2020 13:48:31 +0100
Subject: [PATCH v2 0/8] spelling.txt: /decriptors/descriptors/
Message-ID: <20200715124839.252822-1-kieran.bingham+renesas@ideasonboard.com>

I wouldn't normally go through spelling fixes, but I caught sight of
this typo twice, and then foolishly grepped the tree for it, and saw how
pervasive it was.

so here I am ... fixing a typo globally... but with an addition in
scripts/spelling.txt so it shouldn't re-appear ;-)

V2: Posting before the merge windows close to pick up the last few
non-merged patches, and ideally - to get the actaul spelling.txt entry
picked up, and this time including trivial at kernel.org to let these get
head through that tree if required.

Cc: trivial at kernel.org
Cc: linux-arm-kernel at lists.infradead.org (moderated list:ARM SUB-ARCHITECTURES)
Cc: linux-kernel at vger.kernel.org (open list)
Cc: linux-input at vger.kernel.org (open list:INPUT (KEYBOARD, MOUSE, JOYSTICK, TOUCHSCREEN)...)
Cc: netdev at vger.kernel.org (open list:NETWORKING DRIVERS)
Cc: ath10k at lists.infradead.org (open list:QUALCOMM ATHEROS ATH10K WIRELESS DRIVER)
Cc: linux-wireless at vger.kernel.org (open list:NETWORKING DRIVERS (WIRELESS))
Cc: virtualization at lists.linux-foundation.org (open list:VIRTIO BALLOON)
Cc: linux-mm at kvack.org (open list:MEMORY MANAGEMENT)

Kieran Bingham (17):
  arch: arm: mach-davinci: Fix trivial spelling
  drivers: input: joystick: Fix trivial spelling
  drivers: net: wan: Fix trivial spelling
  drivers: net: wireless: Fix trivial spelling
  include: dynamic_debug.h: Fix trivial spelling
  kernel: trace: Fix trivial spelling
  mm/balloon_compaction: Fix trivial spelling
  scripts/spelling.txt: Add descriptors correction

 arch/arm/mach-davinci/board-da830-evm.c | 2 +-
 drivers/input/joystick/spaceball.c      | 2 +-
 drivers/net/wan/lmc/lmc_main.c          | 2 +-
 drivers/net/wireless/ath/ath10k/usb.c   | 2 +-
 drivers/net/wireless/ath/ath6kl/usb.c   | 2 +-
 drivers/net/wireless/cisco/airo.c       | 2 +-
 include/linux/dynamic_debug.h           | 2 +-
 kernel/trace/trace_events.c             | 2 +-
 mm/balloon_compaction.c                 | 4 ++--
 scripts/spelling.txt                    | 2 ++
 10 files changed, 12 insertions(+), 10 deletions(-)

-- 
2.25.1



From kieran.bingham+renesas at ideasonboard.com  Wed Jul 15 08:48:35 2020
From: kieran.bingham+renesas at ideasonboard.com (Kieran Bingham)
Date: Wed, 15 Jul 2020 13:48:35 +0100
Subject: [PATCH v2 4/8] drivers: net: wireless: Fix trivial spelling
In-Reply-To: <20200715124839.252822-1-kieran.bingham+renesas@ideasonboard.com>
References: <20200715124839.252822-1-kieran.bingham+renesas@ideasonboard.com>
Message-ID: <20200715124839.252822-5-kieran.bingham+renesas@ideasonboard.com>

The word 'descriptor' is misspelled throughout the tree.

Fix it up accordingly:
    decriptors -> descriptors

Signed-off-by: Kieran Bingham <kieran.bingham+renesas at ideasonboard.com>
---
 drivers/net/wireless/ath/ath10k/usb.c | 2 +-
 drivers/net/wireless/ath/ath6kl/usb.c | 2 +-
 drivers/net/wireless/cisco/airo.c     | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/usb.c b/drivers/net/wireless/ath/ath10k/usb.c
index b7daf344d012..05a620ff6fe2 100644
--- a/drivers/net/wireless/ath/ath10k/usb.c
+++ b/drivers/net/wireless/ath/ath10k/usb.c
@@ -824,7 +824,7 @@ static int ath10k_usb_setup_pipe_resources(struct ath10k *ar,
 
 	ath10k_dbg(ar, ATH10K_DBG_USB, "usb setting up pipes using interface\n");
 
-	/* walk decriptors and setup pipes */
+	/* walk descriptors and setup pipes */
 	for (i = 0; i < iface_desc->desc.bNumEndpoints; ++i) {
 		endpoint = &iface_desc->endpoint[i].desc;
 
diff --git a/drivers/net/wireless/ath/ath6kl/usb.c b/drivers/net/wireless/ath/ath6kl/usb.c
index 53b66e9434c9..5372e948e761 100644
--- a/drivers/net/wireless/ath/ath6kl/usb.c
+++ b/drivers/net/wireless/ath/ath6kl/usb.c
@@ -311,7 +311,7 @@ static int ath6kl_usb_setup_pipe_resources(struct ath6kl_usb *ar_usb)
 
 	ath6kl_dbg(ATH6KL_DBG_USB, "setting up USB Pipes using interface\n");
 
-	/* walk decriptors and setup pipes */
+	/* walk descriptors and setup pipes */
 	for (i = 0; i < iface_desc->desc.bNumEndpoints; ++i) {
 		endpoint = &iface_desc->endpoint[i].desc;
 
diff --git a/drivers/net/wireless/cisco/airo.c b/drivers/net/wireless/cisco/airo.c
index 827bb6d74815..e3ad77666ba8 100644
--- a/drivers/net/wireless/cisco/airo.c
+++ b/drivers/net/wireless/cisco/airo.c
@@ -2450,7 +2450,7 @@ static void mpi_unmap_card(struct pci_dev *pci)
 
 /*************************************************************
  *  This routine assumes that descriptors have been setup .
- *  Run at insmod time or after reset  when the decriptors
+ *  Run at insmod time or after reset when the descriptors
  *  have been initialized . Returns 0 if all is well nz
  *  otherwise . Does not allocate memory but sets up card
  *  using previously allocated descriptors.
-- 
2.25.1



From kieran.bingham+renesas at ideasonboard.com  Wed Jul 15 08:52:01 2020
From: kieran.bingham+renesas at ideasonboard.com (Kieran Bingham)
Date: Wed, 15 Jul 2020 13:52:01 +0100
Subject: [PATCH 05/17] drivers: net: Fix trivial spelling
In-Reply-To: <20200715102209.C9012C433A1@smtp.codeaurora.org>
References: <20200609124610.3445662-6-kieran.bingham+renesas@ideasonboard.com>
 <20200715102209.C9012C433A1@smtp.codeaurora.org>
Message-ID: <f32e309f-a214-87c3-68fe-66882b949794@ideasonboard.com>

Hi Kalle,

On 15/07/2020 11:22, Kalle Valo wrote:
> Kieran Bingham <kieran.bingham+renesas at ideasonboard.com> wrote:
> 
>> The word 'descriptor' is misspelled throughout the tree.
>>
>> Fix it up accordingly:
>>     decriptors -> descriptors
>>
>> Signed-off-by: Kieran Bingham <kieran.bingham+renesas at ideasonboard.com>
> 
> I recommend splitting wan and wireless changes to separate patches as I
> cannot take changes to wan subsystem.
> 
> Patch set to Changes Requested.

Thanks, I've split this and resent the remaining outstanding patches.

--
Kieran





From kvalo at codeaurora.org  Wed Jul 15 11:26:56 2020
From: kvalo at codeaurora.org (Kalle Valo)
Date: Wed, 15 Jul 2020 18:26:56 +0300
Subject: [PATCH] net: ath10k: fix OOB: __ath10k_htt_rx_ring_fill_n
In-Reply-To: <20200623221105.3486-1-bruceshenzk@gmail.com> (Zekun Shen's
 message of "Tue, 23 Jun 2020 18:11:05 -0400")
References: <20200623221105.3486-1-bruceshenzk@gmail.com>
Message-ID: <87mu4094u7.fsf@codeaurora.org>

Zekun Shen <bruceshenzk at gmail.com> writes:

> The idx in __ath10k_htt_rx_ring_fill_n function lives in
> consistent dma region writable by the device. Malfunctional
> or malicious device could manipulate such idx to have a OOB
> write. Either by
>     htt->rx_ring.netbufs_ring[idx] = skb;
> or by
>     ath10k_htt_set_paddrs_ring(htt, paddr, idx);
>
> The idx can also be negative as it's signed, giving a large
> memory space to write to.
>
> It's possibly exploitable by corruptting a legit pointer with
> a skb pointer. And then fill skb with payload as rougue object.
>
> Signed-off-by: Zekun Shen <bruceshenzk at gmail.com>
> ---
> Part of the log here. Sometimes it appears as UAF when writing 
> to a freed memory by chance.
>
>  [   15.594376] BUG: unable to handle page fault for address: ffff887f5c1804f0
>  [   15.595483] #PF: supervisor write access in kernel mode
>  [   15.596250] #PF: error_code(0x0002) - not-present page
>  [   15.597013] PGD 0 P4D 0
>  [   15.597395] Oops: 0002 [#1] SMP KASAN PTI
>  [   15.597967] CPU: 0 PID: 82 Comm: kworker/u2:2 Not tainted 5.6.0 #69
>  [   15.598843] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), 
>  BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
>  [   15.600438] Workqueue: ath10k_wq ath10k_core_register_work [ath10k_core]
>  [   15.601389] RIP: 0010:__ath10k_htt_rx_ring_fill_n 
>  (linux/drivers/net/wireless/ath/ath10k/htt_rx.c:173) ath10k_core

I added the log to the commit log as it looks useful.

Also I made minor changes to the title and to the error message.

-- 
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


From kvalo at codeaurora.org  Wed Jul 15 12:48:31 2020
From: kvalo at codeaurora.org (Kalle Valo)
Date: Wed, 15 Jul 2020 16:48:31 +0000 (UTC)
Subject: [PATCH v2 4/8] wireless: Fix trivial spelling
In-Reply-To: <20200715124839.252822-5-kieran.bingham+renesas@ideasonboard.com>
References: <20200715124839.252822-5-kieran.bingham+renesas@ideasonboard.com>
Message-ID: <20200715164831.4A105C433AD@smtp.codeaurora.org>

Kieran Bingham <kieran.bingham+renesas at ideasonboard.com> wrote:

> The word 'descriptor' is misspelled throughout the tree.
> 
> Fix it up accordingly:
>     decriptors -> descriptors
> 
> Signed-off-by: Kieran Bingham <kieran.bingham+renesas at ideasonboard.com>

Patch applied to wireless-drivers-next.git, thanks.

0e20c3e10333 wireless: Fix trivial spelling

-- 
https://patchwork.kernel.org/patch/11665283/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches



From robh at kernel.org  Wed Jul 15 16:21:31 2020
From: robh at kernel.org (Rob Herring)
Date: Wed, 15 Jul 2020 14:21:31 -0600
Subject: [PATCH 1/2] dt: bindings: Add new regulator as optional property
 for WCN3990
In-Reply-To: <1593194502-13164-2-git-send-email-pillair@codeaurora.org>
References: <1593194502-13164-1-git-send-email-pillair@codeaurora.org>
 <1593194502-13164-2-git-send-email-pillair@codeaurora.org>
Message-ID: <20200715202131.GA754725@bogus>

On Fri, 26 Jun 2020 23:31:41 +0530, Rakesh Pillai wrote:
> Add an additional regulator supply as an optional
> property for WCN3990.
> 
> Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.1-01040-QCAHLSWMTPLZ-1
> 
> Signed-off-by: Rakesh Pillai <pillair at codeaurora.org>
> ---
>  Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 

Acked-by: Rob Herring <robh at kernel.org>


From lkp at intel.com  Wed Jul 15 23:55:05 2020
From: lkp at intel.com (kernel test robot)
Date: Thu, 16 Jul 2020 11:55:05 +0800
Subject: [ath6kl:master-pending] BUILD SUCCESS
 6bd9b238e27d889ed438884a0c048701af2493fe
Message-ID: <5f0fcf99.fIwiZ9mB9mJWxyji%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git  master-pending
branch HEAD: 6bd9b238e27d889ed438884a0c048701af2493fe  Merge branch 'pending' into master-pending

elapsed time: 720m

configs tested: 90
configs skipped: 4

The following configs have been built successfully.
More configs may be tested in the coming days.

arm                                 defconfig
arm                              allyesconfig
arm                              allmodconfig
arm                               allnoconfig
arm64                            allyesconfig
arm64                               defconfig
arm64                            allmodconfig
arm64                             allnoconfig
arc                          axs101_defconfig
c6x                        evmc6457_defconfig
sh                 kfr2r09-romimage_defconfig
powerpc                    gamecube_defconfig
arm                          lpd270_defconfig
mips                          malta_defconfig
riscv                               defconfig
c6x                        evmc6474_defconfig
arm                        clps711x_defconfig
arm                           corgi_defconfig
riscv                            allyesconfig
arm                         orion5x_defconfig
i386                              allnoconfig
i386                             allyesconfig
i386                                defconfig
i386                              debian-10.3
ia64                             allmodconfig
ia64                                defconfig
ia64                              allnoconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                              allnoconfig
m68k                           sun3_defconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
nios2                            allyesconfig
openrisc                            defconfig
c6x                              allyesconfig
c6x                               allnoconfig
openrisc                         allyesconfig
nds32                               defconfig
nds32                             allnoconfig
csky                             allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
h8300                            allmodconfig
xtensa                              defconfig
arc                                 defconfig
arc                              allyesconfig
sh                               allmodconfig
sh                                allnoconfig
microblaze                        allnoconfig
mips                             allyesconfig
mips                              allnoconfig
mips                             allmodconfig
parisc                            allnoconfig
parisc                              defconfig
parisc                           allyesconfig
parisc                           allmodconfig
powerpc                          allyesconfig
powerpc                          rhel-kconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
powerpc                             defconfig
i386                 randconfig-a016-20200715
i386                 randconfig-a011-20200715
i386                 randconfig-a015-20200715
i386                 randconfig-a012-20200715
i386                 randconfig-a013-20200715
i386                 randconfig-a014-20200715
riscv                             allnoconfig
riscv                            allmodconfig
s390                             allyesconfig
s390                              allnoconfig
s390                             allmodconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
sparc64                             defconfig
sparc64                           allnoconfig
sparc64                          allyesconfig
sparc64                          allmodconfig
x86_64                    rhel-7.6-kselftests
x86_64                               rhel-8.3
x86_64                                  kexec
x86_64                                   rhel
x86_64                                    lkp
x86_64                              fedora-25

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From kvalo at codeaurora.org  Thu Jul 16 02:38:32 2020
From: kvalo at codeaurora.org (Kalle Valo)
Date: Thu, 16 Jul 2020 09:38:32 +0300
Subject: [PATCH] ath10k: Add interrupt summary based CE processing
In-Reply-To: <CA+ASDXNOCFZhdNMDk9XTuC2H+owQ0+wHipDbkJAGnU9q7BXz_w@mail.gmail.com>
 (Brian Norris's message of "Fri, 26 Jun 2020 14:52:30 -0700")
References: <1593193967-29897-1-git-send-email-pillair@codeaurora.org>
 <CAD=FV=V_ynwukeR92nbJXkuQ7OAW4mLaTjxko7fXt5aEfDUNhA@mail.gmail.com>
 <CAD=FV=XJDmGbEJQ1U-VDuN2p0+V+uRm_1=DwBnDPmPQsXqS4ZA@mail.gmail.com>
 <CA+ASDXNOCFZhdNMDk9XTuC2H+owQ0+wHipDbkJAGnU9q7BXz_w@mail.gmail.com>
Message-ID: <871rlcx8uv.fsf@codeaurora.org>

Brian Norris <briannorris at chromium.org> writes:

> On Fri, Jun 26, 2020 at 2:49 PM Doug Anderson <dianders at chromium.org> wrote:
>> I should also note that, while I'm not terribly familiar with Kalle's
>> workflow, I would have expected to see him in the "To:" list.  I've
>> added him, but it's possible he'll need you to repost the patch with
>> him in the "To:" list.
>
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#who_to_address
> https://wireless.wiki.kernel.org/en/users/drivers/ath10k/submittingpatches
>
> Patchwork is his patch queue, so I don't think you need to address him directly.

Yup, I take all patches from patchwork so no need to Cc me.

-- 
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


From kvalo at codeaurora.org  Thu Jul 16 05:35:20 2020
From: kvalo at codeaurora.org (Kalle Valo)
Date: Thu, 16 Jul 2020 12:35:20 +0300
Subject: [PATCH 1/2] nl80211: vendor-cmd: qca: add dynamic SAR power limits
In-Reply-To: <CA+ASDXMf7iXuE9hQ-XitPPfvXP0EK5FchJLCu2+5Ag=ZC=0H0w@mail.gmail.com>
 (Brian Norris's message of "Mon, 1 Jun 2020 18:32:31 -0700")
References: <1576684108-30177-1-git-send-email-kvalo@codeaurora.org>
 <1576684108-30177-2-git-send-email-kvalo@codeaurora.org>
 <1576748692.7758.17.camel@realtek.com> <20191219154828.GA12287@w1.fi>
 <CA+ASDXMTYLGbEkBPHSqtyitMEvY5o_MjU0s+NoWdnN_ORy1gDw@mail.gmail.com>
 <20191219185522.GA16010@w1.fi>
 <CA+ASDXNOxkrZTxL0Jo4ONR2YtL83BVc_w-rBXc6ggBLdwUpDZw@mail.gmail.com>
 <871rpqly6a.fsf@kamboji.qca.qualcomm.com>
 <e8908eafd8e6050eef8782c6a7019e318d14f65f.camel@sipsolutions.net>
 <CA+ASDXMf7iXuE9hQ-XitPPfvXP0EK5FchJLCu2+5Ag=ZC=0H0w@mail.gmail.com>
Message-ID: <87lfjjx0o7.fsf@codeaurora.org>

Brian Norris <briannorris at chromium.org> writes:

> Really, I could live with per-vendor APIs. My primary goal is to get
> these upstream in some form, so vendors can stop using things like
> this as a reason for shipping us non-upstream code, and so we can
> reduce the delta between upstream and Chrome OS kernels.
>
> I also think that, for the cases that warrant it (i.e., the option 2
> -- Realtek and Qualcomm cases, so far), it would be good to have a
> common API, but that's a somewhat secondary concern for me.

So to me it feels like the best solution forward is to go with the
vendor API, do you agree? We can, of course, later switch to the common
API if we manage to create one which is usable for everyone.

> Also, Kalle had some concerns about stable ABI questions: shouldn't we
> bake in some kind of "check for support" feature to these kinds of
> APIs [3]? That would help ease transition, if we do start with a
> vendor API and move to a common one in the future.

Yeah, that sounds like a good idea but I don't think that should block
these patches.

-- 
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


From pillair at codeaurora.org  Thu Jul 16 07:48:22 2020
From: pillair at codeaurora.org (Rakesh Pillai)
Date: Thu, 16 Jul 2020 17:18:22 +0530
Subject: [PATCH] ath10k: Add history for tracking certain events
In-Reply-To: <859a8ffb-6108-81f3-b379-4a0adfa064fe@candelatech.com>
References: <1593238973-23237-1-git-send-email-pillair@codeaurora.org>
 <926301ed-e27f-0d8f-0177-6484bfffa40c@candelatech.com>
 <000201d64d0a$b3d39d10$1b7ad730$@codeaurora.org>
 <859a8ffb-6108-81f3-b379-4a0adfa064fe@candelatech.com>
Message-ID: <008501d65b67$0743a0c0$15cae240$@codeaurora.org>



> -----Original Message-----
> From: Ben Greear <greearb at candelatech.com>
> Sent: Sunday, June 28, 2020 10:56 PM
> To: Rakesh Pillai <pillair at codeaurora.org>; ath10k at lists.infradead.org
> Cc: linux-wireless at vger.kernel.org; linux-kernel at vger.kernel.org
> Subject: Re: [PATCH] ath10k: Add history for tracking certain events
> 
> 
> 
> On 06/27/2020 10:12 PM, Rakesh Pillai wrote:
> >
> >
> >> -----Original Message-----
> >> From: Ben Greear <greearb at candelatech.com>
> >> Sent: Saturday, June 27, 2020 8:58 PM
> >> To: Rakesh Pillai <pillair at codeaurora.org>; ath10k at lists.infradead.org
> >> Cc: linux-wireless at vger.kernel.org; linux-kernel at vger.kernel.org
> >> Subject: Re: [PATCH] ath10k: Add history for tracking certain events
> >>
> >>
> >>
> >> On 06/26/2020 11:22 PM, Rakesh Pillai wrote:
> >>> For debugging many issues, a history of the
> >>> below mentioned events can help get an idea
> >>> of what exactly was going on just before any
> >>> issue occurred in the system. These event
> >>> history will be collected only when the host
> >>> driver is run in debug mode (i.e. with the
> >>> config ATH10K_DEBUG enabled).
> >>
> >> This should be disabled by default unless user specifically pokes some
> >> debugfs
> >> value to turn it on so that it does not impact performance.
> >
> > Hi Ben,
> > This history is enabled only if the user compiles the kernel with
> > ATH10K_DEBUG.
> > Making it runtime, adds a lot of "if" conditions for this history
record.
> > Do you suggest to add support to enable/disable it runtime even in
> > ATH10K_DEBUG ?
> 
> Yes, because you are adding lots of locks/unlocks.  That is way more
> expensive
> than an if statement.  You can add an 'unlikely' to the if check as well,
so
> compiler will optimize for this feature not being enabled.


Hi Ben,
I missed this mail somehow.
Yes sure, I will make the necessary changes and upload a new patchset.

Thanks,
Rakesh Pillai.


> 
> Thanks,
> Ben
> 
> >
> >>
> >> Thanks,
> >> Ben
> >>
> >>>
> >>> Add history for tracking the below events
> >>> - register read
> >>> - register write
> >>> - IRQ trigger
> >>> - IRQ Enable
> >>> - IRQ Disable
> >>> - NAPI poll
> >>> - CE service
> >>> - WMI cmd
> >>> - WMI event
> >>> - WMI tx completion
> >>>
> >>> This will help in debugging any crash or any
> >>> improper behaviour.
> >>
> >>
> >> --
> >> 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 lkp at intel.com  Thu Jul 16 10:35:24 2020
From: lkp at intel.com (kernel test robot)
Date: Thu, 16 Jul 2020 22:35:24 +0800
Subject: [ath6kl:pending] BUILD SUCCESS
 36704fc513bcb56baec56ad5902dd5551cb2a475
Message-ID: <5f1065ac.g4Sxkm0S1IvJNvL5%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git  pending
branch HEAD: 36704fc513bcb56baec56ad5902dd5551cb2a475  wcn36xx: Fix software-driven scan

elapsed time: 1361m

configs tested: 133
configs skipped: 6

The following configs have been built successfully.
More configs may be tested in the coming days.

arm                                 defconfig
arm                              allyesconfig
arm                              allmodconfig
arm                               allnoconfig
arm64                            allyesconfig
arm64                               defconfig
arm64                            allmodconfig
arm64                             allnoconfig
arc                          axs101_defconfig
c6x                        evmc6457_defconfig
sh                 kfr2r09-romimage_defconfig
powerpc                    gamecube_defconfig
arm                          lpd270_defconfig
i386                             allyesconfig
mips                          malta_defconfig
riscv                               defconfig
c6x                        evmc6474_defconfig
riscv                    nommu_k210_defconfig
powerpc                  mpc866_ads_defconfig
arm                       mainstone_defconfig
arm                      tct_hammer_defconfig
powerpc                        cell_defconfig
powerpc                       holly_defconfig
mips                       capcella_defconfig
sparc                       sparc32_defconfig
sh                            shmin_defconfig
arm                        clps711x_defconfig
arm                           corgi_defconfig
riscv                            allyesconfig
arm                         orion5x_defconfig
mips                           ip28_defconfig
ia64                              allnoconfig
powerpc                     pseries_defconfig
powerpc64                        alldefconfig
mips                      maltasmvp_defconfig
i386                              allnoconfig
i386                                defconfig
i386                              debian-10.3
ia64                             allmodconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                              allnoconfig
m68k                           sun3_defconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
nios2                            allyesconfig
openrisc                            defconfig
c6x                              allyesconfig
c6x                               allnoconfig
openrisc                         allyesconfig
nds32                               defconfig
nds32                             allnoconfig
csky                             allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
h8300                            allmodconfig
xtensa                              defconfig
arc                                 defconfig
arc                              allyesconfig
sh                               allmodconfig
sh                                allnoconfig
microblaze                        allnoconfig
mips                             allyesconfig
mips                              allnoconfig
mips                             allmodconfig
parisc                            allnoconfig
parisc                              defconfig
parisc                           allyesconfig
parisc                           allmodconfig
powerpc                             defconfig
powerpc                          allyesconfig
powerpc                          rhel-kconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
x86_64               randconfig-a005-20200715
x86_64               randconfig-a006-20200715
x86_64               randconfig-a002-20200715
x86_64               randconfig-a001-20200715
x86_64               randconfig-a003-20200715
x86_64               randconfig-a004-20200715
i386                 randconfig-a001-20200716
i386                 randconfig-a005-20200716
i386                 randconfig-a002-20200716
i386                 randconfig-a006-20200716
i386                 randconfig-a003-20200716
i386                 randconfig-a004-20200716
i386                 randconfig-a001-20200715
i386                 randconfig-a005-20200715
i386                 randconfig-a002-20200715
i386                 randconfig-a006-20200715
i386                 randconfig-a003-20200715
i386                 randconfig-a004-20200715
x86_64               randconfig-a012-20200716
x86_64               randconfig-a011-20200716
x86_64               randconfig-a016-20200716
x86_64               randconfig-a014-20200716
x86_64               randconfig-a013-20200716
x86_64               randconfig-a015-20200716
i386                 randconfig-a016-20200716
i386                 randconfig-a011-20200716
i386                 randconfig-a015-20200716
i386                 randconfig-a012-20200716
i386                 randconfig-a013-20200716
i386                 randconfig-a014-20200716
i386                 randconfig-a016-20200715
i386                 randconfig-a011-20200715
i386                 randconfig-a015-20200715
i386                 randconfig-a012-20200715
i386                 randconfig-a013-20200715
i386                 randconfig-a014-20200715
riscv                             allnoconfig
riscv                            allmodconfig
s390                             allyesconfig
s390                              allnoconfig
s390                             allmodconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
sparc64                             defconfig
sparc64                           allnoconfig
sparc64                          allyesconfig
sparc64                          allmodconfig
x86_64                    rhel-7.6-kselftests
x86_64                               rhel-8.3
x86_64                                  kexec
x86_64                                   rhel
x86_64                                    lkp
x86_64                              fedora-25

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From briannorris at chromium.org  Thu Jul 16 14:56:39 2020
From: briannorris at chromium.org (Brian Norris)
Date: Thu, 16 Jul 2020 11:56:39 -0700
Subject: [PATCH 1/2] nl80211: vendor-cmd: qca: add dynamic SAR power limits
In-Reply-To: <87lfjjx0o7.fsf@codeaurora.org>
References: <1576684108-30177-1-git-send-email-kvalo@codeaurora.org>
 <1576684108-30177-2-git-send-email-kvalo@codeaurora.org>
 <1576748692.7758.17.camel@realtek.com>
 <20191219154828.GA12287@w1.fi>
 <CA+ASDXMTYLGbEkBPHSqtyitMEvY5o_MjU0s+NoWdnN_ORy1gDw@mail.gmail.com>
 <20191219185522.GA16010@w1.fi>
 <CA+ASDXNOxkrZTxL0Jo4ONR2YtL83BVc_w-rBXc6ggBLdwUpDZw@mail.gmail.com>
 <871rpqly6a.fsf@kamboji.qca.qualcomm.com>
 <e8908eafd8e6050eef8782c6a7019e318d14f65f.camel@sipsolutions.net>
 <CA+ASDXMf7iXuE9hQ-XitPPfvXP0EK5FchJLCu2+5Ag=ZC=0H0w@mail.gmail.com>
 <87lfjjx0o7.fsf@codeaurora.org>
Message-ID: <CA+ASDXOAzPuOn_rMsRj4t56kC-TgoG0p5WhSTPJjB8xTTq5kfg@mail.gmail.com>

On Thu, Jul 16, 2020 at 2:35 AM Kalle Valo <kvalo at codeaurora.org> wrote:
> Brian Norris <briannorris at chromium.org> writes:
> > Really, I could live with per-vendor APIs. My primary goal is to get
> > these upstream in some form, so vendors can stop using things like
> > this as a reason for shipping us non-upstream code, and so we can
> > reduce the delta between upstream and Chrome OS kernels.
> >
> > I also think that, for the cases that warrant it (i.e., the option 2
> > -- Realtek and Qualcomm cases, so far), it would be good to have a
> > common API, but that's a somewhat secondary concern for me.
>
> So to me it feels like the best solution forward is to go with the
> vendor API, do you agree? We can, of course, later switch to the common
> API if we manage to create one which is usable for everyone.

That's fine with me. That's pretty much what I said in my first email:

"Anyway, I don't really object with starting out with a
Qualcomm-specific and a Realtek-specific vendor command to implement
nearly the same feature, but I'd prefer if people did engage in some
healthy discussion about why they can't share an API, with the hopes
that maybe they can converge someday."

I think we've had some healthy (though very protracted) discussion,
and I don't think I've seen anyone bring up anything I wasn't already
aware of that would prevent eventual consolidation. As long as we
acknowledge those things (item 2 at
https://wireless.wiki.kernel.org/en/developers/documentation/nl80211#vendor-specific_api),
I'm happy.

> > Also, Kalle had some concerns about stable ABI questions: shouldn't we
> > bake in some kind of "check for support" feature to these kinds of
> > APIs [3]? That would help ease transition, if we do start with a
> > vendor API and move to a common one in the future.
>
> Yeah, that sounds like a good idea but I don't think that should block
> these patches.

OK, well it was your concern first, IIRC :)

So what's next? A v2 that only needs a bit of updated description
about "why a vendor API"? And Realtek can feel free to submit this [1]
shortly?

Thanks,
Brian

[1] Series: rtw88: Add SAR implementation
https://patchwork.kernel.org/project/linux-wireless/list/?series=238219&state=*


From kvalo at codeaurora.org  Mon Jul 20 13:10:35 2020
From: kvalo at codeaurora.org (Kalle Valo)
Date: Mon, 20 Jul 2020 17:10:35 +0000 (UTC)
Subject: [PATCH] net: ath10k: fix OOB: __ath10k_htt_rx_ring_fill_n
In-Reply-To: <20200623221105.3486-1-bruceshenzk@gmail.com>
References: <20200623221105.3486-1-bruceshenzk@gmail.com>
Message-ID: <20200720171035.C5974C433C6@smtp.codeaurora.org>

Zekun Shen <bruceshenzk at gmail.com> wrote:

> The idx in __ath10k_htt_rx_ring_fill_n function lives in
> consistent dma region writable by the device. Malfunctional
> or malicious device could manipulate such idx to have a OOB
> write. Either by
>     htt->rx_ring.netbufs_ring[idx] = skb;
> or by
>     ath10k_htt_set_paddrs_ring(htt, paddr, idx);
> 
> The idx can also be negative as it's signed, giving a large
> memory space to write to.
> 
> It's possibly exploitable by corruptting a legit pointer with
> a skb pointer. And then fill skb with payload as rougue object.
> 
> Part of the log here. Sometimes it appears as UAF when writing
> to a freed memory by chance.
> 
>  [   15.594376] BUG: unable to handle page fault for address: ffff887f5c1804f0
>  [   15.595483] #PF: supervisor write access in kernel mode
>  [   15.596250] #PF: error_code(0x0002) - not-present page
>  [   15.597013] PGD 0 P4D 0
>  [   15.597395] Oops: 0002 [#1] SMP KASAN PTI
>  [   15.597967] CPU: 0 PID: 82 Comm: kworker/u2:2 Not tainted 5.6.0 #69
>  [   15.598843] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
>  BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
>  [   15.600438] Workqueue: ath10k_wq ath10k_core_register_work [ath10k_core]
>  [   15.601389] RIP: 0010:__ath10k_htt_rx_ring_fill_n
>  (linux/drivers/net/wireless/ath/ath10k/htt_rx.c:173) ath10k_core
> 
> Signed-off-by: Zekun Shen <bruceshenzk at gmail.com>
> Signed-off-by: Kalle Valo <kvalo at codeaurora.org>

Patch applied to ath-next branch of ath.git, thanks.

bad60b8d1a71 ath10k: check idx validity in __ath10k_htt_rx_ring_fill_n()

-- 
https://patchwork.kernel.org/patch/11621899/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches



From kvalo at codeaurora.org  Mon Jul 20 13:24:19 2020
From: kvalo at codeaurora.org (Kalle Valo)
Date: Mon, 20 Jul 2020 17:24:19 +0000 (UTC)
Subject: [PATCH v5.8] ath10k: Fix NULL pointer dereference in AHB device
 probe
In-Reply-To: <20200714205802.17688-1-hauke@hauke-m.de>
References: <20200714205802.17688-1-hauke@hauke-m.de>
Message-ID: <20200720172419.282C0C433CA@smtp.codeaurora.org>

Hauke Mehrtens <hauke at hauke-m.de> wrote:

> This fixes a NULL pointer dereference in the probe path for AHB devices.
> There attr parameter in the ath10k_ce_alloc_pipe() function is not
> initialized, but accessed. This function is called by
> ath10k_pci_setup_resource() which is called by ath10k_ahb_probe().
> 
> The struct ath10k_pci is also used for AHB devices and not only for PCI
> devices.
> 
> The initialization of the new members of struct ath10k_pci is moved to
> ath10k_pci_setup_resource() which is used by the PCI and the AHB code.
> 
> This also fixes a use after free bug in ath10k_pci_remove() when ar_pci
> is accessed after ath10k_core_destroy() was called, which calls
> ieee80211_free_hw() and frees this memory.
> 
> This fixes the following bug seen with backports-5.8-rc2 on OpenWrt on a
> IPQ4019 device:
> 
> [   11.117462] 8<--- cut here ---
> [   11.117494] Unable to handle kernel NULL pointer dereference at virtual address 00000000
> [   11.119510] pgd = f377fd58
> [   11.127657] [00000000] *pgd=8e9a0835, *pte=00000000, *ppte=00000000
> [   11.130206] Internal error: Oops: 17 [#1] SMP ARM
> [   11.136339] Modules linked in: ath10k_pci(+) ath10k_core ath xt_state xt_nat xt_conntrack xt_REDIRECT xt_MASQUERADE xt_FLOWOFFLOAD pppox ppp_generic nf_nat nf_flow_table_hw nf_flow_table nf_conntrack_rtcache nf_conntrack mac80211 ipt_REJECT cfg80211 xt_time xt_tcpudp xt_multiport xt_mark xt_mac xt_limit xt_comment xt_TCPMSS xt_LOG slhc nf_reject_ipv4 nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 iptable_mangle iptable_filter ip_tables crc_ccitt compat nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 leds_gpio xhci_plat_hcd xhci_pci xhci_hcd dwc3 dwc3_qcom gpio_button_hotplug
> [   11.174355] CPU: 2 PID: 257 Comm: kmodloader Not tainted 5.4.51 #0
> [   11.196585] Hardware name: Generic DT based system
> [   11.202746] PC is at ath10k_ce_alloc_pipe+0x58/0x180 [ath10k_core]
> [   11.207459] LR is at ath10k_pci_alloc_pipes+0x94/0xc8 [ath10k_pci]
> [   11.213600] pc : [<bf2c96cc>]    lr : [<bf2fbf98>]    psr: 80000013
> [   11.219760] sp : cea0dc90  ip : cf4001f0  fp : 00000001
> [   11.225923] r10: 00000000  r9 : 00000018  r8 : ce4963b4
> [   11.231133] r7 : 00000000  r6 : ce491ea0  r5 : 00000000  r4 : ce4963b4
> [   11.236342] r3 : 0004a000  r2 : 0004a000  r1 : bf2d0d70  r0 : 00000006
> [   11.242942] Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
> [   11.249452] Control: 10c5387d  Table: 8e9c006a  DAC: 00000051
> [   11.256656] Process kmodloader (pid: 257, stack limit = 0xaba286ca)
> [   11.262386] Stack: (0xcea0dc90 to 0xcea0e000)
> [   11.268462] dc80:                                     00000000 ce49629c ce491ea0 ce4963bc
> [   11.272984] dca0: ce495ea0 bf2fbf98 00000002 ce4963a8 ce495ea0 00000000 ce491ea0 cf95d800
> [   11.281142] dcc0: cf95d810 cf95d810 00000001 bf2fc854 00000000 cf95d800 bf300748 ce495ea0
> [   11.289304] dce0: ce491ea0 d1300000 cf95d800 bf2fde8c 00000000 00000001 ce49cea0 00000000
> [   11.297462] dd00: 00000000 00000000 bf3010a0 cf95d810 bf3010a0 c0b61580 00000000 00000000
> [   11.305624] dd20: bf3010a0 0000000b c0b04e48 c06110c8 c0b61588 cf95d810 c0b61580 c060f740
> [   11.313781] dd40: cf95d810 00000000 bf3010a0 00000000 00000000 ce49d2a4 bf301100 c060fc90
> [   11.321943] dd60: 00000000 bf3010a0 cf95d810 c060fcf0 cf95d810 bf3010a0 c060fc98 c060dca4
> [   11.330101] dd80: cf809d58 cf952cb4 bf3010a0 ce967900 c0b1f2c8 c060ec28 bf3007b8 bf301038
> [   11.338263] dda0: bf3010a0 bf3010a0 c0b2d4d4 ffffe000 bf304000 c0610278 c0b04e48 c0b2d4d4
> [   11.346422] ddc0: ffffe000 bf2fe2b4 c0b04e48 bf30403c c0b04e48 c0302764 8040003f 00000001
> [   11.354582] dde0: 38e38e39 ce513580 c0b2cb50 cf801e00 cffbc6ac ce513600 cf801e00 cffbc6ac
> [   11.362740] de00: 8040003e ce49d280 00000001 c0428d54 00000001 cf801e00 cffbc6ac ce513580
> [   11.370900] de20: ce49d280 0e391998 bf301100 ce49d340 d12d2000 ce49d280 00000001 c0398c2c
> [   11.379061] de40: 00000001 cea0df34 cea0df34 00000001 d12d2000 c039ae48 bf30110c 00007fff
> [   11.387221] de60: bf301100 c0398044 cf804028 bf301148 c0397674 bf30126c c08ee5c0 c08ee70c
> [   11.395380] de80: bf30110c c0b04e48 c08ee518 00000000 c08ee570 c0b04e48 ce513600 fffff000
> [   11.403540] dea0: 00000001 ce513580 0000000d 0000000d 00000000 00000000 00000000 00000000
> [   11.411698] dec0: 00000000 00000000 6e72656b 00006c65 00000000 00000000 00000000 00000000
> [   11.419858] dee0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> [   11.428018] df00: 00000000 0e391998 00000000 0000c610 d12de610 00000000 0062c620 ffffe000
> [   11.436180] df20: 000129d1 00000051 00000000 c039b228 00000000 d12d7afd d12d8e80 d12d2000
> [   11.444337] df40: 0000c610 d12de0e8 d12ddfa8 d12dab74 00009000 00009570 00003a2c 00009cae
> [   11.452498] df60: 00000000 00000000 00000000 00003a1c 0000001e 0000001f 00000018 00000000
> [   11.460656] df80: 00000010 00000000 00000000 00000000 00000003 00000080 c0301204 cea0c000
> [   11.468817] dfa0: 00000080 c0301000 00000000 00000000 00620010 0000c610 000129d1 00000014
> [   11.476975] dfc0: 00000000 00000000 00000003 00000080 0000c610 00000000 b6fc1d20 00000000
> [   11.485137] dfe0: bef0ad14 bef0acf8 00011e14 b6f74c94 60000010 00620010 00000000 00000000
> [   11.493390] [<bf2c96cc>] (ath10k_ce_alloc_pipe [ath10k_core]) from [<bf2fbf98>] (ath10k_pci_alloc_pipes+0x94/0xc8 [ath10k_pci])
> [   11.501498] [<bf2fbf98>] (ath10k_pci_alloc_pipes [ath10k_pci]) from [<bf2fc854>] (ath10k_pci_setup_resource+0xb8/0xf0 [ath10k_pci])
> [   11.512773] [<bf2fc854>] (ath10k_pci_setup_resource [ath10k_pci]) from [<bf2fde8c>] (ath10k_ahb_probe+0x32c/0x670 [ath10k_pci])
> [   11.524566] [<bf2fde8c>] (ath10k_ahb_probe [ath10k_pci]) from [<c06110c8>] (platform_drv_probe+0x34/0x70)
> [   11.536016] [<c06110c8>] (platform_drv_probe) from [<c060f740>] (really_probe+0x1f0/0x358)
> [   11.545729] [<c060f740>] (really_probe) from [<c060fc90>] (device_driver_attach+0x58/0x60)
> [   11.553886] [<c060fc90>] (device_driver_attach) from [<c060fcf0>] (__driver_attach+0x58/0xcc)
> [   11.562134] [<c060fcf0>] (__driver_attach) from [<c060dca4>] (bus_for_each_dev+0x68/0x8c)
> [   11.570731] [<c060dca4>] (bus_for_each_dev) from [<c060ec28>] (bus_add_driver+0x1c8/0x1d8)
> [   11.578886] [<c060ec28>] (bus_add_driver) from [<c0610278>] (driver_register+0x74/0x108)
> [   11.587060] [<c0610278>] (driver_register) from [<bf2fe2b4>] (ath10k_ahb_init+0x18/0x38 [ath10k_pci])
> [   11.595320] [<bf2fe2b4>] (ath10k_ahb_init [ath10k_pci]) from [<bf30403c>] (init_module+0x3c/0x1000 [ath10k_pci])
> [   11.604432] [<bf30403c>] (init_module [ath10k_pci]) from [<c0302764>] (do_one_initcall+0x84/0x1d8)
> [   11.614657] [<c0302764>] (do_one_initcall) from [<c0398c2c>] (do_init_module+0x5c/0x228)
> [   11.623421] [<c0398c2c>] (do_init_module) from [<c039ae48>] (load_module+0x1fc8/0x224c)
> [   11.631663] [<c039ae48>] (load_module) from [<c039b228>] (sys_init_module+0x15c/0x17c)
> [   11.639390] [<c039b228>] (sys_init_module) from [<c0301000>] (ret_fast_syscall+0x0/0x54)
> [   11.647370] Exception stack(0xcea0dfa8 to 0xcea0dff0)
> [   11.655615] dfa0:                   00000000 00000000 00620010 0000c610 000129d1 00000014
> [   11.660569] dfc0: 00000000 00000000 00000003 00000080 0000c610 00000000 b6fc1d20 00000000
> [   11.668725] dfe0: bef0ad14 bef0acf8 00011e14 b6f74c94
> [   11.676886] Code: e1c321d4 e0433002 e0232397 e5843014 (e5953000)
> [   11.681958] ---[ end trace 8f35917de2e76854 ]---
> 
> Fixes: 521fc37be3d8 ("ath10k: Avoid override CE5 configuration for QCA99X0 chipsets")
> Reported-by: Stefan Lippers-Hollmann <s.l-h at gmx.de> [ipq40xx/ map-ac2200]
> Signed-off-by: Hauke Mehrtens <hauke at hauke-m.de>

Patch applied to wireless-drivers.git, thanks.

1cfd3426ef98 ath10k: Fix NULL pointer dereference in AHB device probe

-- 
https://patchwork.kernel.org/patch/11663789/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches



From peter.oh at eero.com  Mon Jul 20 20:33:28 2020
From: peter.oh at eero.com (Peter Oh)
Date: Mon, 20 Jul 2020 17:33:28 -0700
Subject: [PATCH] ath10k: Add interrupt summary based CE processing
In-Reply-To: <871rlcx8uv.fsf@codeaurora.org>
References: <1593193967-29897-1-git-send-email-pillair@codeaurora.org>
 <CAD=FV=V_ynwukeR92nbJXkuQ7OAW4mLaTjxko7fXt5aEfDUNhA@mail.gmail.com>
 <CAD=FV=XJDmGbEJQ1U-VDuN2p0+V+uRm_1=DwBnDPmPQsXqS4ZA@mail.gmail.com>
 <CA+ASDXNOCFZhdNMDk9XTuC2H+owQ0+wHipDbkJAGnU9q7BXz_w@mail.gmail.com>
 <871rlcx8uv.fsf@codeaurora.org>
Message-ID: <CALhWmc1PbTKhrkaPn9yfpx3gZHAMuR-bPY=4_o4wQHv_H5D9dA@mail.gmail.com>

I'm getting this panic on IPQ4019 system after cherry-picked this
single patch on top of working system.

[   14.226184] ath10k_ahb a000000.wifi: failed to receive initialized
event from target: 80000000
[   14.326406] !#%&PageFault P<find_dr+0x28/0x64>
L<devres_remove+0x38/0x70> F<005> [00000008]
[   14.326447] Unable to handle kernel NULL pointer dereference at
virtual address 00000008
[   14.333569] pgd = 80cac000
[   14.341892] [00000008] *pgd=00000000
[   14.347804] !#%&Abort P<find_dr+0x28/0x64>
L<devres_remove+0x38/0x70> F<005> FILE<PageFault>
[   14.348067] Internal error: PageFault: 5 [#1] PREEMPT SMP ARM
[   14.356568] Modules linked in: ath10k_pci(+) ecm shortcut_fe_drv
shortcut_fe ath10k_core ath mac80211 cfg80211 compat
[   14.372537] CPU: 3 PID: 301 Comm: systemd-modules Not tainted
4.4.60-yocto-standard-eero #1
[   14.372805] Hardware name: Qualcomm (Flattened Device Tree)
[   14.380961] task: 9b492300 ti: 9d3f0000 task.ti: 9d3f0000
[   14.386516] PC is at find_dr+0x28/0x64
[   14.392069] LR is at devres_remove+0x38/0x70
[   14.395720] pc : [<804aa498>]    lr : [<804aa564>]    psr: 00010193
[   14.395720] sp : 9d3f7cc8  ip : 00000000  fp : 7f18b380
[   14.400155] r10: 9d995610  r9 : 9b73db64  r8 : 9b740b00
[   14.411343] r7 : 80430990  r6 : 8043097c  r5 : 9b73da10  r4 : 00000000
[   14.416554] r3 : 9b740b00  r2 : 8043097c  r1 : 80430990  r0 : 9b73da10
[   14.423153] Flags: nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM
Segment user
[   14.429663] Control: 10c5387d  Table: 80cac06a  DAC: 00000055
[   14.436865] Process systemd-modules (pid: 301, stack limit = 0x9d3f0210)
[   14.442683] Stack: (0x9d3f7cc8 to 0x9d3f8000)
[   14.449455] 7cc0:                   9b73da10 a0010113 80430990
8043097c 9b740b00 9b73db60
[   14.453716] 7ce0: 9d995610 804aa564 9b740b00 9dbd1f20 9d995600
9d995600 ffffff92 00000000
[   14.461876] 7d00: 9d995610 804aac4c 9b740b00 80430a94 9dbd5f20
7f28c584 9dbd5f20 7f28cf28
[   14.470035] 7d20: 7f28f3b2 9dbd1f20 00000001 9cae5960 9d9a16e0
00000000 00000000 00000000
[   14.478196] 7d40: 8162d420 7f28c9d4 9d995610 7f28fb94 8162d42c
815a59e0 8162d420 00000003
[   14.486355] 7d60: 9d3f7f54 804a96cc 9d995610 00000000 7f28fb94
804a7df8 7f28fb94 9d995610
[   14.494516] 7d80: 9d995610 7f28fb94 9d995644 815d8400 00000000
0000001c 9cae60c8 804a7f9c
[   14.502675] 7da0: 00000000 7f28fb94 804a7f50 804a62c0 9d81fc5c
9d9f6634 7f28fb94 9b739a00
[   14.510834] 7dc0: 815a5908 804a7344 7f28f3b2 7f28f3b3 7f28fb94
7f293000 00000000 815b6d48
[   14.518995] 7de0: 815b6d48 804a87a4 9cae61c0 7f293000 00000000
7f28d2e8 9cae61c0 7f29300c
[   14.527153] 7e00: 9cae61c0 80213468 0018bce1 00000001 8040003f
802b19d0 9e34ea98 00000000
[   14.535315] 7e20: 9e34eaa8 9e34ea98 8040003e 9e34e8a0 9e34e8a0
9bae8100 9d3f0000 9d801e40
[   14.543474] 7e40: 00004eb1 9e34e8a0 9bae8080 9d3f0000 81621200
7f28fc00 00000001 81599848
[   14.551632] 7e60: 7f28fc00 00000001 9cae6180 7f28fc48 00000001
80287704 7f28fc00 9e34e8a0
[   14.559793] 7e80: 7f28fc00 00000001 9cae60c0 80289298 7f28fc0c
00007fff 7f28fc00 80286a58
[   14.567952] 7ea0: 00000000 815998c4 a13e1138 7f293100 a13dba30
8088bd0c 7f28fdc4 76cea5cc
[   14.576112] 7ec0: 9d3f7f54 802861d4 00000000 00000000 00000000
00000000 00000000 00000000
[   14.584269] 7ee0: 6e72656b 00006c65 00000000 00000000 00000000
00000000 00000000 00000000
[   14.592430] 7f00: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 81599848
[   14.600590] 7f20: 00000000 00000000 76cea5cc 00000008 0000017b
80209de4 9d3f0000 00000000
[   14.608751] 7f40: 00000000 80289594 9d3f0000 00000000 7e85fbbc
a13d4000 0000d1b0 a13e0b48
[   14.616911] 7f60: a13e09ac a13dd590 00007e08 00008ca8 00000000
00000000 00000000 0000313c
[   14.625070] 7f80: 00000026 00000027 0000001d 00000000 00000016
00000000 00000000 00000000
[   14.633230] 7fa0: 5654ca48 80209c40 00000000 00000000 00000008
76cea5cc 00000000 00000000
[   14.641390] 7fc0: 00000000 00000000 5654ca48 0000017b 00000000
00000001 76ea754f 00000000
[   14.649549] 7fe0: 7e85fbc0 7e85fbb0 76ce281c 76c6b830 600f0010
00000008 00000000 00000000
[   14.657717] [<804aa498>] (find_dr) from [<804aa564>]
(devres_remove+0x38/0x70)
[   14.665868] [<804aa564>] (devres_remove) from [<804aac4c>]
(devres_destroy+0x8/0x24)
[   14.672989] [<804aac4c>] (devres_destroy) from [<80430a94>]
(devm_iounmap+0x18/0x44)
[   14.680927] [<80430a94>] (devm_iounmap) from [<7f28c584>]
(ath10k_ahb_resource_deinit+0x20/0x74 [ath10k_pci])
[   14.688671] [<7f28c584>] (ath10k_ahb_resource_deinit [ath10k_pci])
from [<7f28cf28>] (ath10k_ahb_probe+0x554/0x6f4 [ath10k_pci])
[   14.698454] [<7f28cf28>] (ath10k_ahb_probe [ath10k_pci]) from
[<804a96cc>] (platform_drv_probe+0x50/0x9c)
[   14.710061] [<804a96cc>] (platform_drv_probe) from [<804a7df8>]
(driver_probe_device+0x2ac/0x404)
[   14.719520] [<804a7df8>] (driver_probe_device) from [<804a7f9c>]
(__driver_attach+0x4c/0x8c)
[   14.728374] [<804a7f9c>] (__driver_attach) from [<804a62c0>]
(bus_for_each_dev+0x7c/0x8c)
[   14.736880] [<804a62c0>] (bus_for_each_dev) from [<804a7344>]
(bus_add_driver+0x1b4/0x234)
[   14.744952] [<804a7344>] (bus_add_driver) from [<804a87a4>]
(driver_register+0xa0/0xe0)
[   14.753136] [<804a87a4>] (driver_register) from [<7f28d2e8>]
(ath10k_ahb_init+0x10/0x38 [ath10k_pci])
[   14.761061] [<7f28d2e8>] (ath10k_ahb_init [ath10k_pci]) from
[<7f29300c>] (__init_backport+0xc/0x100 [ath10k_pci])
[   14.770418] [<7f29300c>] (__init_backport [ath10k_pci]) from
[<80213468>] (do_one_initcall+0x1c4/0x20c)
[   14.780633] [<80213468>] (do_one_initcall) from [<80287704>]
(do_init_module+0x54/0x1ac)
[   14.789916] [<80287704>] (do_init_module) from [<80289298>]
(load_module+0x19e0/0x1b04)
[   14.798249] [<80289298>] (load_module) from [<80289594>]
(SyS_finit_module+0x8c/0x9c)
[   14.805975] [<80289594>] (SyS_finit_module) from [<80209c40>]
(ret_fast_syscall+0x0/0x34)
[   14.813959] Code: e1a08003 e1540009 03a04000 0a00000c (e5943008)
[   14.822108] ---[ end trace f4da008c1c165fb3 ]---
[   14.830623] Kernel panic - not syncing: Fatal exception
[   14.832876] CPU1: stopping
[   14.837820] CPU: 1 PID: 343 Comm: rngd Tainted: G      D
4.4.60-yocto-standard-eero #1
[   14.840601] Hardware name: Qualcomm (Flattened Device Tree)
[   14.849210] [<8021ed7c>] (unwind_backtrace) from [<8021b730>]
(show_stack+0x10/0x14)
[   14.854672] [<8021b730>] (show_stack) from [<8041b8dc>]
(dump_stack+0x7c/0x98)
[   14.862658] [<8041b8dc>] (dump_stack) from [<8021dfc8>]
(handle_IPI+0xdc/0x164)
[   14.869688] [<8021dfc8>] (handle_IPI) from [<802093e8>]
(gic_handle_irq+0x80/0x8c)
[   14.876893] [<802093e8>] (gic_handle_irq) from [<8020a844>]
(__irq_usr+0x44/0x60)
[   14.884524] Exception stack(0x9beaffb0 to 0x9beafff8)
[   14.892076] ffa0:                                     0c27987c
40016b9f 0c27987d 0000001f
[   14.897118] ffc0: 00000001 763fedbc 565a344c 54b3de80 54b3e50c
00000001 7e817c00 763fed0c
[   14.905277] ffe0: fffffffe 763fecc0 00000018 76ec3e18 30010010 ffffffff
[   14.913430] CPU2: stopping
[   14.919849] CPU: 2 PID: 344 Comm: rngd Tainted: G      D
4.4.60-yocto-standard-eero #1
[   14.922631] Hardware name: Qualcomm (Flattened Device Tree)
[   14.931236] [<8021ed7c>] (unwind_backtrace) from [<8021b730>]
(show_stack+0x10/0x14)
[   14.936703] [<8021b730>] (show_stack) from [<8041b8dc>]
(dump_stack+0x7c/0x98)
[   14.944688] [<8041b8dc>] (dump_stack) from [<8021dfc8>]
(handle_IPI+0xdc/0x164)
[   14.951719] [<8021dfc8>] (handle_IPI) from [<802093e8>]
(gic_handle_irq+0x80/0x8c)
[   14.958924] [<802093e8>] (gic_handle_irq) from [<8020a844>]
(__irq_usr+0x44/0x60)
[   14.966554] Exception stack(0x9beb7fb0 to 0x9beb7ff8)
[   14.974107] 7fa0:                                     fffffff7
00000017 a6000000 0000014a
[   14.979150] 7fc0: 00000002 759fedbc 565a3470 54b3de80 54b3e50c
00000001 7e817c00 759fed0c
[   14.987307] 7fe0: 00000009 759fecc0 00000018 76ec3cdc 80010010 ffffffff
[   14.995461] CPU0: stopping
[   15.001882] CPU: 0 PID: 341 Comm: rngd Tainted: G      D
4.4.60-yocto-standard-eero #1
[   15.004663] Hardware name: Qualcomm (Flattened Device Tree)
[   15.013267] [<8021ed7c>] (unwind_backtrace) from [<8021b730>]
(show_stack+0x10/0x14)
[   15.018734] [<8021b730>] (show_stack) from [<8041b8dc>]
(dump_stack+0x7c/0x98)
[   15.026719] [<8041b8dc>] (dump_stack) from [<8021dfc8>]
(handle_IPI+0xdc/0x164)
[   15.033752] [<8021dfc8>] (handle_IPI) from [<802093e8>]
(gic_handle_irq+0x80/0x8c)
[   15.040955] [<802093e8>] (gic_handle_irq) from [<8020a844>]
(__irq_usr+0x44/0x60)
[   15.048585] Exception stack(0x9be87fb0 to 0x9be87ff8)
[   15.056139] 7fa0:                                     00000000
00000000 a7e3391d 6a11d866
[   15.061181] 7fc0: 00000000 76d15dbc 565a3428 54b3de80 54b3e50c
00000001 7e817c00 76d15d0c
[   15.069339] 7fe0: ffffffeb 76d15cc0 00000018 76ec3d60 80010010 ffffffff
[   15.091080] Rebooting in 5 seconds..


On Wed, Jul 15, 2020 at 11:39 PM Kalle Valo <kvalo at codeaurora.org> wrote:
>
> Brian Norris <briannorris at chromium.org> writes:
>
> > On Fri, Jun 26, 2020 at 2:49 PM Doug Anderson <dianders at chromium.org> wrote:
> >> I should also note that, while I'm not terribly familiar with Kalle's
> >> workflow, I would have expected to see him in the "To:" list.  I've
> >> added him, but it's possible he'll need you to repost the patch with
> >> him in the "To:" list.
> >
> > https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#who_to_address
> > https://wireless.wiki.kernel.org/en/users/drivers/ath10k/submittingpatches
> >
> > Patchwork is his patch queue, so I don't think you need to address him directly.
>
> Yup, I take all patches from patchwork so no need to Cc me.
>
> --
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


From dianders at chromium.org  Mon Jul 20 20:40:02 2020
From: dianders at chromium.org (Doug Anderson)
Date: Mon, 20 Jul 2020 17:40:02 -0700
Subject: [PATCH] ath10k: Add interrupt summary based CE processing
In-Reply-To: <CALhWmc1PbTKhrkaPn9yfpx3gZHAMuR-bPY=4_o4wQHv_H5D9dA@mail.gmail.com>
References: <1593193967-29897-1-git-send-email-pillair@codeaurora.org>
 <CAD=FV=V_ynwukeR92nbJXkuQ7OAW4mLaTjxko7fXt5aEfDUNhA@mail.gmail.com>
 <CAD=FV=XJDmGbEJQ1U-VDuN2p0+V+uRm_1=DwBnDPmPQsXqS4ZA@mail.gmail.com>
 <CA+ASDXNOCFZhdNMDk9XTuC2H+owQ0+wHipDbkJAGnU9q7BXz_w@mail.gmail.com>
 <871rlcx8uv.fsf@codeaurora.org>
 <CALhWmc1PbTKhrkaPn9yfpx3gZHAMuR-bPY=4_o4wQHv_H5D9dA@mail.gmail.com>
Message-ID: <CAD=FV=XUpwVoxNPELFfWnKRYFornTFMvtgFaOgD7ij-fQNEvmQ@mail.gmail.com>

Hi,

On Mon, Jul 20, 2020 at 5:33 PM Peter Oh <peter.oh at eero.com> wrote:
>
> I'm getting this panic on IPQ4019 system after cherry-picked this
> single patch on top of working system.
>
> [   14.226184] ath10k_ahb a000000.wifi: failed to receive initialized
> event from target: 80000000

A bit of a shot in the dark, but any chance you could try this atop it
and see if it helps?

https://lore.kernel.org/r/20200709082024.v2.1.I4d2f85ffa06f38532631e864a3125691ef5ffe06 at changeid/

...most of this patch is gutted by that one.

-Doug


From peter.oh at eero.com  Mon Jul 20 20:43:58 2020
From: peter.oh at eero.com (Peter Oh)
Date: Mon, 20 Jul 2020 17:43:58 -0700
Subject: [PATCH] ath10k: Add interrupt summary based CE processing
In-Reply-To: <CALhWmc1PbTKhrkaPn9yfpx3gZHAMuR-bPY=4_o4wQHv_H5D9dA@mail.gmail.com>
References: <1593193967-29897-1-git-send-email-pillair@codeaurora.org>
 <CAD=FV=V_ynwukeR92nbJXkuQ7OAW4mLaTjxko7fXt5aEfDUNhA@mail.gmail.com>
 <CAD=FV=XJDmGbEJQ1U-VDuN2p0+V+uRm_1=DwBnDPmPQsXqS4ZA@mail.gmail.com>
 <CA+ASDXNOCFZhdNMDk9XTuC2H+owQ0+wHipDbkJAGnU9q7BXz_w@mail.gmail.com>
 <871rlcx8uv.fsf@codeaurora.org>
 <CALhWmc1PbTKhrkaPn9yfpx3gZHAMuR-bPY=4_o4wQHv_H5D9dA@mail.gmail.com>
Message-ID: <CALhWmc3i9Z+KiG1cJNvpSWNsiFhOa5jBw=XfcFz_gKwi_5QibA@mail.gmail.com>

I've run 3 units and one of them happens the problem always while the
other 2 are barely happening.

On Mon, Jul 20, 2020 at 5:33 PM Peter Oh <peter.oh at eero.com> wrote:
>
> I'm getting this panic on IPQ4019 system after cherry-picked this
> single patch on top of working system.
>
> [   14.226184] ath10k_ahb a000000.wifi: failed to receive initialized
> event from target: 80000000
> [   14.326406] !#%&PageFault P<find_dr+0x28/0x64>
> L<devres_remove+0x38/0x70> F<005> [00000008]
> [   14.326447] Unable to handle kernel NULL pointer dereference at
> virtual address 00000008
> [   14.333569] pgd = 80cac000
> [   14.341892] [00000008] *pgd=00000000
> [   14.347804] !#%&Abort P<find_dr+0x28/0x64>
> L<devres_remove+0x38/0x70> F<005> FILE<PageFault>
> [   14.348067] Internal error: PageFault: 5 [#1] PREEMPT SMP ARM
> [   14.356568] Modules linked in: ath10k_pci(+) ecm shortcut_fe_drv
> shortcut_fe ath10k_core ath mac80211 cfg80211 compat
> [   14.372537] CPU: 3 PID: 301 Comm: systemd-modules Not tainted
> 4.4.60-yocto-standard-eero #1
> [   14.372805] Hardware name: Qualcomm (Flattened Device Tree)
> [   14.380961] task: 9b492300 ti: 9d3f0000 task.ti: 9d3f0000
> [   14.386516] PC is at find_dr+0x28/0x64
> [   14.392069] LR is at devres_remove+0x38/0x70
> [   14.395720] pc : [<804aa498>]    lr : [<804aa564>]    psr: 00010193
> [   14.395720] sp : 9d3f7cc8  ip : 00000000  fp : 7f18b380
> [   14.400155] r10: 9d995610  r9 : 9b73db64  r8 : 9b740b00
> [   14.411343] r7 : 80430990  r6 : 8043097c  r5 : 9b73da10  r4 : 00000000
> [   14.416554] r3 : 9b740b00  r2 : 8043097c  r1 : 80430990  r0 : 9b73da10
> [   14.423153] Flags: nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM
> Segment user
> [   14.429663] Control: 10c5387d  Table: 80cac06a  DAC: 00000055
> [   14.436865] Process systemd-modules (pid: 301, stack limit = 0x9d3f0210)
> [   14.442683] Stack: (0x9d3f7cc8 to 0x9d3f8000)
> [   14.449455] 7cc0:                   9b73da10 a0010113 80430990
> 8043097c 9b740b00 9b73db60
> [   14.453716] 7ce0: 9d995610 804aa564 9b740b00 9dbd1f20 9d995600
> 9d995600 ffffff92 00000000
> [   14.461876] 7d00: 9d995610 804aac4c 9b740b00 80430a94 9dbd5f20
> 7f28c584 9dbd5f20 7f28cf28
> [   14.470035] 7d20: 7f28f3b2 9dbd1f20 00000001 9cae5960 9d9a16e0
> 00000000 00000000 00000000
> [   14.478196] 7d40: 8162d420 7f28c9d4 9d995610 7f28fb94 8162d42c
> 815a59e0 8162d420 00000003
> [   14.486355] 7d60: 9d3f7f54 804a96cc 9d995610 00000000 7f28fb94
> 804a7df8 7f28fb94 9d995610
> [   14.494516] 7d80: 9d995610 7f28fb94 9d995644 815d8400 00000000
> 0000001c 9cae60c8 804a7f9c
> [   14.502675] 7da0: 00000000 7f28fb94 804a7f50 804a62c0 9d81fc5c
> 9d9f6634 7f28fb94 9b739a00
> [   14.510834] 7dc0: 815a5908 804a7344 7f28f3b2 7f28f3b3 7f28fb94
> 7f293000 00000000 815b6d48
> [   14.518995] 7de0: 815b6d48 804a87a4 9cae61c0 7f293000 00000000
> 7f28d2e8 9cae61c0 7f29300c
> [   14.527153] 7e00: 9cae61c0 80213468 0018bce1 00000001 8040003f
> 802b19d0 9e34ea98 00000000
> [   14.535315] 7e20: 9e34eaa8 9e34ea98 8040003e 9e34e8a0 9e34e8a0
> 9bae8100 9d3f0000 9d801e40
> [   14.543474] 7e40: 00004eb1 9e34e8a0 9bae8080 9d3f0000 81621200
> 7f28fc00 00000001 81599848
> [   14.551632] 7e60: 7f28fc00 00000001 9cae6180 7f28fc48 00000001
> 80287704 7f28fc00 9e34e8a0
> [   14.559793] 7e80: 7f28fc00 00000001 9cae60c0 80289298 7f28fc0c
> 00007fff 7f28fc00 80286a58
> [   14.567952] 7ea0: 00000000 815998c4 a13e1138 7f293100 a13dba30
> 8088bd0c 7f28fdc4 76cea5cc
> [   14.576112] 7ec0: 9d3f7f54 802861d4 00000000 00000000 00000000
> 00000000 00000000 00000000
> [   14.584269] 7ee0: 6e72656b 00006c65 00000000 00000000 00000000
> 00000000 00000000 00000000
> [   14.592430] 7f00: 00000000 00000000 00000000 00000000 00000000
> 00000000 00000000 81599848
> [   14.600590] 7f20: 00000000 00000000 76cea5cc 00000008 0000017b
> 80209de4 9d3f0000 00000000
> [   14.608751] 7f40: 00000000 80289594 9d3f0000 00000000 7e85fbbc
> a13d4000 0000d1b0 a13e0b48
> [   14.616911] 7f60: a13e09ac a13dd590 00007e08 00008ca8 00000000
> 00000000 00000000 0000313c
> [   14.625070] 7f80: 00000026 00000027 0000001d 00000000 00000016
> 00000000 00000000 00000000
> [   14.633230] 7fa0: 5654ca48 80209c40 00000000 00000000 00000008
> 76cea5cc 00000000 00000000
> [   14.641390] 7fc0: 00000000 00000000 5654ca48 0000017b 00000000
> 00000001 76ea754f 00000000
> [   14.649549] 7fe0: 7e85fbc0 7e85fbb0 76ce281c 76c6b830 600f0010
> 00000008 00000000 00000000
> [   14.657717] [<804aa498>] (find_dr) from [<804aa564>]
> (devres_remove+0x38/0x70)
> [   14.665868] [<804aa564>] (devres_remove) from [<804aac4c>]
> (devres_destroy+0x8/0x24)
> [   14.672989] [<804aac4c>] (devres_destroy) from [<80430a94>]
> (devm_iounmap+0x18/0x44)
> [   14.680927] [<80430a94>] (devm_iounmap) from [<7f28c584>]
> (ath10k_ahb_resource_deinit+0x20/0x74 [ath10k_pci])
> [   14.688671] [<7f28c584>] (ath10k_ahb_resource_deinit [ath10k_pci])
> from [<7f28cf28>] (ath10k_ahb_probe+0x554/0x6f4 [ath10k_pci])
> [   14.698454] [<7f28cf28>] (ath10k_ahb_probe [ath10k_pci]) from
> [<804a96cc>] (platform_drv_probe+0x50/0x9c)
> [   14.710061] [<804a96cc>] (platform_drv_probe) from [<804a7df8>]
> (driver_probe_device+0x2ac/0x404)
> [   14.719520] [<804a7df8>] (driver_probe_device) from [<804a7f9c>]
> (__driver_attach+0x4c/0x8c)
> [   14.728374] [<804a7f9c>] (__driver_attach) from [<804a62c0>]
> (bus_for_each_dev+0x7c/0x8c)
> [   14.736880] [<804a62c0>] (bus_for_each_dev) from [<804a7344>]
> (bus_add_driver+0x1b4/0x234)
> [   14.744952] [<804a7344>] (bus_add_driver) from [<804a87a4>]
> (driver_register+0xa0/0xe0)
> [   14.753136] [<804a87a4>] (driver_register) from [<7f28d2e8>]
> (ath10k_ahb_init+0x10/0x38 [ath10k_pci])
> [   14.761061] [<7f28d2e8>] (ath10k_ahb_init [ath10k_pci]) from
> [<7f29300c>] (__init_backport+0xc/0x100 [ath10k_pci])
> [   14.770418] [<7f29300c>] (__init_backport [ath10k_pci]) from
> [<80213468>] (do_one_initcall+0x1c4/0x20c)
> [   14.780633] [<80213468>] (do_one_initcall) from [<80287704>]
> (do_init_module+0x54/0x1ac)
> [   14.789916] [<80287704>] (do_init_module) from [<80289298>]
> (load_module+0x19e0/0x1b04)
> [   14.798249] [<80289298>] (load_module) from [<80289594>]
> (SyS_finit_module+0x8c/0x9c)
> [   14.805975] [<80289594>] (SyS_finit_module) from [<80209c40>]
> (ret_fast_syscall+0x0/0x34)
> [   14.813959] Code: e1a08003 e1540009 03a04000 0a00000c (e5943008)
> [   14.822108] ---[ end trace f4da008c1c165fb3 ]---
> [   14.830623] Kernel panic - not syncing: Fatal exception
> [   14.832876] CPU1: stopping
> [   14.837820] CPU: 1 PID: 343 Comm: rngd Tainted: G      D
> 4.4.60-yocto-standard-eero #1
> [   14.840601] Hardware name: Qualcomm (Flattened Device Tree)
> [   14.849210] [<8021ed7c>] (unwind_backtrace) from [<8021b730>]
> (show_stack+0x10/0x14)
> [   14.854672] [<8021b730>] (show_stack) from [<8041b8dc>]
> (dump_stack+0x7c/0x98)
> [   14.862658] [<8041b8dc>] (dump_stack) from [<8021dfc8>]
> (handle_IPI+0xdc/0x164)
> [   14.869688] [<8021dfc8>] (handle_IPI) from [<802093e8>]
> (gic_handle_irq+0x80/0x8c)
> [   14.876893] [<802093e8>] (gic_handle_irq) from [<8020a844>]
> (__irq_usr+0x44/0x60)
> [   14.884524] Exception stack(0x9beaffb0 to 0x9beafff8)
> [   14.892076] ffa0:                                     0c27987c
> 40016b9f 0c27987d 0000001f
> [   14.897118] ffc0: 00000001 763fedbc 565a344c 54b3de80 54b3e50c
> 00000001 7e817c00 763fed0c
> [   14.905277] ffe0: fffffffe 763fecc0 00000018 76ec3e18 30010010 ffffffff
> [   14.913430] CPU2: stopping
> [   14.919849] CPU: 2 PID: 344 Comm: rngd Tainted: G      D
> 4.4.60-yocto-standard-eero #1
> [   14.922631] Hardware name: Qualcomm (Flattened Device Tree)
> [   14.931236] [<8021ed7c>] (unwind_backtrace) from [<8021b730>]
> (show_stack+0x10/0x14)
> [   14.936703] [<8021b730>] (show_stack) from [<8041b8dc>]
> (dump_stack+0x7c/0x98)
> [   14.944688] [<8041b8dc>] (dump_stack) from [<8021dfc8>]
> (handle_IPI+0xdc/0x164)
> [   14.951719] [<8021dfc8>] (handle_IPI) from [<802093e8>]
> (gic_handle_irq+0x80/0x8c)
> [   14.958924] [<802093e8>] (gic_handle_irq) from [<8020a844>]
> (__irq_usr+0x44/0x60)
> [   14.966554] Exception stack(0x9beb7fb0 to 0x9beb7ff8)
> [   14.974107] 7fa0:                                     fffffff7
> 00000017 a6000000 0000014a
> [   14.979150] 7fc0: 00000002 759fedbc 565a3470 54b3de80 54b3e50c
> 00000001 7e817c00 759fed0c
> [   14.987307] 7fe0: 00000009 759fecc0 00000018 76ec3cdc 80010010 ffffffff
> [   14.995461] CPU0: stopping
> [   15.001882] CPU: 0 PID: 341 Comm: rngd Tainted: G      D
> 4.4.60-yocto-standard-eero #1
> [   15.004663] Hardware name: Qualcomm (Flattened Device Tree)
> [   15.013267] [<8021ed7c>] (unwind_backtrace) from [<8021b730>]
> (show_stack+0x10/0x14)
> [   15.018734] [<8021b730>] (show_stack) from [<8041b8dc>]
> (dump_stack+0x7c/0x98)
> [   15.026719] [<8041b8dc>] (dump_stack) from [<8021dfc8>]
> (handle_IPI+0xdc/0x164)
> [   15.033752] [<8021dfc8>] (handle_IPI) from [<802093e8>]
> (gic_handle_irq+0x80/0x8c)
> [   15.040955] [<802093e8>] (gic_handle_irq) from [<8020a844>]
> (__irq_usr+0x44/0x60)
> [   15.048585] Exception stack(0x9be87fb0 to 0x9be87ff8)
> [   15.056139] 7fa0:                                     00000000
> 00000000 a7e3391d 6a11d866
> [   15.061181] 7fc0: 00000000 76d15dbc 565a3428 54b3de80 54b3e50c
> 00000001 7e817c00 76d15d0c
> [   15.069339] 7fe0: ffffffeb 76d15cc0 00000018 76ec3d60 80010010 ffffffff
> [   15.091080] Rebooting in 5 seconds..
>
>
> On Wed, Jul 15, 2020 at 11:39 PM Kalle Valo <kvalo at codeaurora.org> wrote:
> >
> > Brian Norris <briannorris at chromium.org> writes:
> >
> > > On Fri, Jun 26, 2020 at 2:49 PM Doug Anderson <dianders at chromium.org> wrote:
> > >> I should also note that, while I'm not terribly familiar with Kalle's
> > >> workflow, I would have expected to see him in the "To:" list.  I've
> > >> added him, but it's possible he'll need you to repost the patch with
> > >> him in the "To:" list.
> > >
> > > https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#who_to_address
> > > https://wireless.wiki.kernel.org/en/users/drivers/ath10k/submittingpatches
> > >
> > > Patchwork is his patch queue, so I don't think you need to address him directly.
> >
> > Yup, I take all patches from patchwork so no need to Cc me.
> >
> > --
> > https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


From peter.oh at eero.com  Mon Jul 20 20:56:29 2020
From: peter.oh at eero.com (Peter Oh)
Date: Mon, 20 Jul 2020 17:56:29 -0700
Subject: [PATCH] ath10k: Add interrupt summary based CE processing
In-Reply-To: <CALhWmc1B0+SONV6_AF+nUzgxZdekPD3sZuhrsmwVQx1Q-cgT_g@mail.gmail.com>
References: <1593193967-29897-1-git-send-email-pillair@codeaurora.org>
 <CAD=FV=V_ynwukeR92nbJXkuQ7OAW4mLaTjxko7fXt5aEfDUNhA@mail.gmail.com>
 <CAD=FV=XJDmGbEJQ1U-VDuN2p0+V+uRm_1=DwBnDPmPQsXqS4ZA@mail.gmail.com>
 <CA+ASDXNOCFZhdNMDk9XTuC2H+owQ0+wHipDbkJAGnU9q7BXz_w@mail.gmail.com>
 <871rlcx8uv.fsf@codeaurora.org>
 <CALhWmc1PbTKhrkaPn9yfpx3gZHAMuR-bPY=4_o4wQHv_H5D9dA@mail.gmail.com>
 <CALhWmc3i9Z+KiG1cJNvpSWNsiFhOa5jBw=XfcFz_gKwi_5QibA@mail.gmail.com>
 <CALhWmc1B0+SONV6_AF+nUzgxZdekPD3sZuhrsmwVQx1Q-cgT_g@mail.gmail.com>
Message-ID: <CALhWmc0qF5stKRcikjwbeFmE-32hNCDazgQdqTMidUyt7u-T1Q@mail.gmail.com>

Since IPQ4019 doesn't support per CE based interrupt summary, I doubt
if this change is correct.
+       ath10k_ce_engine_int_status_clear(ar, ctrl_addr,
+                                         wm_regs->cc_mask | wm_regs->wm_mask);


On Mon, Jul 20, 2020 at 5:53 PM Peter Oh <peter.oh at eero.com> wrote:
>
> At first I gave these 3 patches.
> ath10k: Add interrupt summary based CE processing
>     https://patchwork.kernel.org/patch/11628299/
> ath10k: Keep track of which interrupts fired, don't poll them
>     https://patchwork.kernel.org/patch/11654631/
> ath10k: Get rid of "per_ce_irq" hw param
>     https://patchwork.kernel.org/patch/11654633/
> and saw the crash happen and then reverted the top 2 and used the very first one, but it is still happening.
>
>
>
> On Mon, Jul 20, 2020 at 5:43 PM Peter Oh <peter.oh at eero.com> wrote:
>>
>> I've run 3 units and one of them happens the problem always while the
>> other 2 are barely happening.
>>
>> On Mon, Jul 20, 2020 at 5:33 PM Peter Oh <peter.oh at eero.com> wrote:
>> >
>> > I'm getting this panic on IPQ4019 system after cherry-picked this
>> > single patch on top of working system.
>> >
>> > [   14.226184] ath10k_ahb a000000.wifi: failed to receive initialized
>> > event from target: 80000000
>> > [   14.326406] !#%&PageFault P<find_dr+0x28/0x64>
>> > L<devres_remove+0x38/0x70> F<005> [00000008]
>> > [   14.326447] Unable to handle kernel NULL pointer dereference at
>> > virtual address 00000008
>> > [   14.333569] pgd = 80cac000
>> > [   14.341892] [00000008] *pgd=00000000
>> > [   14.347804] !#%&Abort P<find_dr+0x28/0x64>
>> > L<devres_remove+0x38/0x70> F<005> FILE<PageFault>
>> > [   14.348067] Internal error: PageFault: 5 [#1] PREEMPT SMP ARM
>> > [   14.356568] Modules linked in: ath10k_pci(+) ecm shortcut_fe_drv
>> > shortcut_fe ath10k_core ath mac80211 cfg80211 compat
>> > [   14.372537] CPU: 3 PID: 301 Comm: systemd-modules Not tainted
>> > 4.4.60-yocto-standard-eero #1
>> > [   14.372805] Hardware name: Qualcomm (Flattened Device Tree)
>> > [   14.380961] task: 9b492300 ti: 9d3f0000 task.ti: 9d3f0000
>> > [   14.386516] PC is at find_dr+0x28/0x64
>> > [   14.392069] LR is at devres_remove+0x38/0x70
>> > [   14.395720] pc : [<804aa498>]    lr : [<804aa564>]    psr: 00010193
>> > [   14.395720] sp : 9d3f7cc8  ip : 00000000  fp : 7f18b380
>> > [   14.400155] r10: 9d995610  r9 : 9b73db64  r8 : 9b740b00
>> > [   14.411343] r7 : 80430990  r6 : 8043097c  r5 : 9b73da10  r4 : 00000000
>> > [   14.416554] r3 : 9b740b00  r2 : 8043097c  r1 : 80430990  r0 : 9b73da10
>> > [   14.423153] Flags: nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM
>> > Segment user
>> > [   14.429663] Control: 10c5387d  Table: 80cac06a  DAC: 00000055
>> > [   14.436865] Process systemd-modules (pid: 301, stack limit = 0x9d3f0210)
>> > [   14.442683] Stack: (0x9d3f7cc8 to 0x9d3f8000)
>> > [   14.449455] 7cc0:                   9b73da10 a0010113 80430990
>> > 8043097c 9b740b00 9b73db60
>> > [   14.453716] 7ce0: 9d995610 804aa564 9b740b00 9dbd1f20 9d995600
>> > 9d995600 ffffff92 00000000
>> > [   14.461876] 7d00: 9d995610 804aac4c 9b740b00 80430a94 9dbd5f20
>> > 7f28c584 9dbd5f20 7f28cf28
>> > [   14.470035] 7d20: 7f28f3b2 9dbd1f20 00000001 9cae5960 9d9a16e0
>> > 00000000 00000000 00000000
>> > [   14.478196] 7d40: 8162d420 7f28c9d4 9d995610 7f28fb94 8162d42c
>> > 815a59e0 8162d420 00000003
>> > [   14.486355] 7d60: 9d3f7f54 804a96cc 9d995610 00000000 7f28fb94
>> > 804a7df8 7f28fb94 9d995610
>> > [   14.494516] 7d80: 9d995610 7f28fb94 9d995644 815d8400 00000000
>> > 0000001c 9cae60c8 804a7f9c
>> > [   14.502675] 7da0: 00000000 7f28fb94 804a7f50 804a62c0 9d81fc5c
>> > 9d9f6634 7f28fb94 9b739a00
>> > [   14.510834] 7dc0: 815a5908 804a7344 7f28f3b2 7f28f3b3 7f28fb94
>> > 7f293000 00000000 815b6d48
>> > [   14.518995] 7de0: 815b6d48 804a87a4 9cae61c0 7f293000 00000000
>> > 7f28d2e8 9cae61c0 7f29300c
>> > [   14.527153] 7e00: 9cae61c0 80213468 0018bce1 00000001 8040003f
>> > 802b19d0 9e34ea98 00000000
>> > [   14.535315] 7e20: 9e34eaa8 9e34ea98 8040003e 9e34e8a0 9e34e8a0
>> > 9bae8100 9d3f0000 9d801e40
>> > [   14.543474] 7e40: 00004eb1 9e34e8a0 9bae8080 9d3f0000 81621200
>> > 7f28fc00 00000001 81599848
>> > [   14.551632] 7e60: 7f28fc00 00000001 9cae6180 7f28fc48 00000001
>> > 80287704 7f28fc00 9e34e8a0
>> > [   14.559793] 7e80: 7f28fc00 00000001 9cae60c0 80289298 7f28fc0c
>> > 00007fff 7f28fc00 80286a58
>> > [   14.567952] 7ea0: 00000000 815998c4 a13e1138 7f293100 a13dba30
>> > 8088bd0c 7f28fdc4 76cea5cc
>> > [   14.576112] 7ec0: 9d3f7f54 802861d4 00000000 00000000 00000000
>> > 00000000 00000000 00000000
>> > [   14.584269] 7ee0: 6e72656b 00006c65 00000000 00000000 00000000
>> > 00000000 00000000 00000000
>> > [   14.592430] 7f00: 00000000 00000000 00000000 00000000 00000000
>> > 00000000 00000000 81599848
>> > [   14.600590] 7f20: 00000000 00000000 76cea5cc 00000008 0000017b
>> > 80209de4 9d3f0000 00000000
>> > [   14.608751] 7f40: 00000000 80289594 9d3f0000 00000000 7e85fbbc
>> > a13d4000 0000d1b0 a13e0b48
>> > [   14.616911] 7f60: a13e09ac a13dd590 00007e08 00008ca8 00000000
>> > 00000000 00000000 0000313c
>> > [   14.625070] 7f80: 00000026 00000027 0000001d 00000000 00000016
>> > 00000000 00000000 00000000
>> > [   14.633230] 7fa0: 5654ca48 80209c40 00000000 00000000 00000008
>> > 76cea5cc 00000000 00000000
>> > [   14.641390] 7fc0: 00000000 00000000 5654ca48 0000017b 00000000
>> > 00000001 76ea754f 00000000
>> > [   14.649549] 7fe0: 7e85fbc0 7e85fbb0 76ce281c 76c6b830 600f0010
>> > 00000008 00000000 00000000
>> > [   14.657717] [<804aa498>] (find_dr) from [<804aa564>]
>> > (devres_remove+0x38/0x70)
>> > [   14.665868] [<804aa564>] (devres_remove) from [<804aac4c>]
>> > (devres_destroy+0x8/0x24)
>> > [   14.672989] [<804aac4c>] (devres_destroy) from [<80430a94>]
>> > (devm_iounmap+0x18/0x44)
>> > [   14.680927] [<80430a94>] (devm_iounmap) from [<7f28c584>]
>> > (ath10k_ahb_resource_deinit+0x20/0x74 [ath10k_pci])
>> > [   14.688671] [<7f28c584>] (ath10k_ahb_resource_deinit [ath10k_pci])
>> > from [<7f28cf28>] (ath10k_ahb_probe+0x554/0x6f4 [ath10k_pci])
>> > [   14.698454] [<7f28cf28>] (ath10k_ahb_probe [ath10k_pci]) from
>> > [<804a96cc>] (platform_drv_probe+0x50/0x9c)
>> > [   14.710061] [<804a96cc>] (platform_drv_probe) from [<804a7df8>]
>> > (driver_probe_device+0x2ac/0x404)
>> > [   14.719520] [<804a7df8>] (driver_probe_device) from [<804a7f9c>]
>> > (__driver_attach+0x4c/0x8c)
>> > [   14.728374] [<804a7f9c>] (__driver_attach) from [<804a62c0>]
>> > (bus_for_each_dev+0x7c/0x8c)
>> > [   14.736880] [<804a62c0>] (bus_for_each_dev) from [<804a7344>]
>> > (bus_add_driver+0x1b4/0x234)
>> > [   14.744952] [<804a7344>] (bus_add_driver) from [<804a87a4>]
>> > (driver_register+0xa0/0xe0)
>> > [   14.753136] [<804a87a4>] (driver_register) from [<7f28d2e8>]
>> > (ath10k_ahb_init+0x10/0x38 [ath10k_pci])
>> > [   14.761061] [<7f28d2e8>] (ath10k_ahb_init [ath10k_pci]) from
>> > [<7f29300c>] (__init_backport+0xc/0x100 [ath10k_pci])
>> > [   14.770418] [<7f29300c>] (__init_backport [ath10k_pci]) from
>> > [<80213468>] (do_one_initcall+0x1c4/0x20c)
>> > [   14.780633] [<80213468>] (do_one_initcall) from [<80287704>]
>> > (do_init_module+0x54/0x1ac)
>> > [   14.789916] [<80287704>] (do_init_module) from [<80289298>]
>> > (load_module+0x19e0/0x1b04)
>> > [   14.798249] [<80289298>] (load_module) from [<80289594>]
>> > (SyS_finit_module+0x8c/0x9c)
>> > [   14.805975] [<80289594>] (SyS_finit_module) from [<80209c40>]
>> > (ret_fast_syscall+0x0/0x34)
>> > [   14.813959] Code: e1a08003 e1540009 03a04000 0a00000c (e5943008)
>> > [   14.822108] ---[ end trace f4da008c1c165fb3 ]---
>> > [   14.830623] Kernel panic - not syncing: Fatal exception
>> > [   14.832876] CPU1: stopping
>> > [   14.837820] CPU: 1 PID: 343 Comm: rngd Tainted: G      D
>> > 4.4.60-yocto-standard-eero #1
>> > [   14.840601] Hardware name: Qualcomm (Flattened Device Tree)
>> > [   14.849210] [<8021ed7c>] (unwind_backtrace) from [<8021b730>]
>> > (show_stack+0x10/0x14)
>> > [   14.854672] [<8021b730>] (show_stack) from [<8041b8dc>]
>> > (dump_stack+0x7c/0x98)
>> > [   14.862658] [<8041b8dc>] (dump_stack) from [<8021dfc8>]
>> > (handle_IPI+0xdc/0x164)
>> > [   14.869688] [<8021dfc8>] (handle_IPI) from [<802093e8>]
>> > (gic_handle_irq+0x80/0x8c)
>> > [   14.876893] [<802093e8>] (gic_handle_irq) from [<8020a844>]
>> > (__irq_usr+0x44/0x60)
>> > [   14.884524] Exception stack(0x9beaffb0 to 0x9beafff8)
>> > [   14.892076] ffa0:                                     0c27987c
>> > 40016b9f 0c27987d 0000001f
>> > [   14.897118] ffc0: 00000001 763fedbc 565a344c 54b3de80 54b3e50c
>> > 00000001 7e817c00 763fed0c
>> > [   14.905277] ffe0: fffffffe 763fecc0 00000018 76ec3e18 30010010 ffffffff
>> > [   14.913430] CPU2: stopping
>> > [   14.919849] CPU: 2 PID: 344 Comm: rngd Tainted: G      D
>> > 4.4.60-yocto-standard-eero #1
>> > [   14.922631] Hardware name: Qualcomm (Flattened Device Tree)
>> > [   14.931236] [<8021ed7c>] (unwind_backtrace) from [<8021b730>]
>> > (show_stack+0x10/0x14)
>> > [   14.936703] [<8021b730>] (show_stack) from [<8041b8dc>]
>> > (dump_stack+0x7c/0x98)
>> > [   14.944688] [<8041b8dc>] (dump_stack) from [<8021dfc8>]
>> > (handle_IPI+0xdc/0x164)
>> > [   14.951719] [<8021dfc8>] (handle_IPI) from [<802093e8>]
>> > (gic_handle_irq+0x80/0x8c)
>> > [   14.958924] [<802093e8>] (gic_handle_irq) from [<8020a844>]
>> > (__irq_usr+0x44/0x60)
>> > [   14.966554] Exception stack(0x9beb7fb0 to 0x9beb7ff8)
>> > [   14.974107] 7fa0:                                     fffffff7
>> > 00000017 a6000000 0000014a
>> > [   14.979150] 7fc0: 00000002 759fedbc 565a3470 54b3de80 54b3e50c
>> > 00000001 7e817c00 759fed0c
>> > [   14.987307] 7fe0: 00000009 759fecc0 00000018 76ec3cdc 80010010 ffffffff
>> > [   14.995461] CPU0: stopping
>> > [   15.001882] CPU: 0 PID: 341 Comm: rngd Tainted: G      D
>> > 4.4.60-yocto-standard-eero #1
>> > [   15.004663] Hardware name: Qualcomm (Flattened Device Tree)
>> > [   15.013267] [<8021ed7c>] (unwind_backtrace) from [<8021b730>]
>> > (show_stack+0x10/0x14)
>> > [   15.018734] [<8021b730>] (show_stack) from [<8041b8dc>]
>> > (dump_stack+0x7c/0x98)
>> > [   15.026719] [<8041b8dc>] (dump_stack) from [<8021dfc8>]
>> > (handle_IPI+0xdc/0x164)
>> > [   15.033752] [<8021dfc8>] (handle_IPI) from [<802093e8>]
>> > (gic_handle_irq+0x80/0x8c)
>> > [   15.040955] [<802093e8>] (gic_handle_irq) from [<8020a844>]
>> > (__irq_usr+0x44/0x60)
>> > [   15.048585] Exception stack(0x9be87fb0 to 0x9be87ff8)
>> > [   15.056139] 7fa0:                                     00000000
>> > 00000000 a7e3391d 6a11d866
>> > [   15.061181] 7fc0: 00000000 76d15dbc 565a3428 54b3de80 54b3e50c
>> > 00000001 7e817c00 76d15d0c
>> > [   15.069339] 7fe0: ffffffeb 76d15cc0 00000018 76ec3d60 80010010 ffffffff
>> > [   15.091080] Rebooting in 5 seconds..
>> >
>> >
>> > On Wed, Jul 15, 2020 at 11:39 PM Kalle Valo <kvalo at codeaurora.org> wrote:
>> > >
>> > > Brian Norris <briannorris at chromium.org> writes:
>> > >
>> > > > On Fri, Jun 26, 2020 at 2:49 PM Doug Anderson <dianders at chromium.org> wrote:
>> > > >> I should also note that, while I'm not terribly familiar with Kalle's
>> > > >> workflow, I would have expected to see him in the "To:" list.  I've
>> > > >> added him, but it's possible he'll need you to repost the patch with
>> > > >> him in the "To:" list.
>> > > >
>> > > > https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#who_to_address
>> > > > https://wireless.wiki.kernel.org/en/users/drivers/ath10k/submittingpatches
>> > > >
>> > > > Patchwork is his patch queue, so I don't think you need to address him directly.
>> > >
>> > > Yup, I take all patches from patchwork so no need to Cc me.
>> > >
>> > > --
>> > > https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


From peter.oh at eero.com  Mon Jul 20 20:58:42 2020
From: peter.oh at eero.com (Peter Oh)
Date: Mon, 20 Jul 2020 17:58:42 -0700
Subject: [PATCH] ath10k: Add interrupt summary based CE processing
In-Reply-To: <CALhWmc0qF5stKRcikjwbeFmE-32hNCDazgQdqTMidUyt7u-T1Q@mail.gmail.com>
References: <1593193967-29897-1-git-send-email-pillair@codeaurora.org>
 <CAD=FV=V_ynwukeR92nbJXkuQ7OAW4mLaTjxko7fXt5aEfDUNhA@mail.gmail.com>
 <CAD=FV=XJDmGbEJQ1U-VDuN2p0+V+uRm_1=DwBnDPmPQsXqS4ZA@mail.gmail.com>
 <CA+ASDXNOCFZhdNMDk9XTuC2H+owQ0+wHipDbkJAGnU9q7BXz_w@mail.gmail.com>
 <871rlcx8uv.fsf@codeaurora.org>
 <CALhWmc1PbTKhrkaPn9yfpx3gZHAMuR-bPY=4_o4wQHv_H5D9dA@mail.gmail.com>
 <CALhWmc3i9Z+KiG1cJNvpSWNsiFhOa5jBw=XfcFz_gKwi_5QibA@mail.gmail.com>
 <CALhWmc1B0+SONV6_AF+nUzgxZdekPD3sZuhrsmwVQx1Q-cgT_g@mail.gmail.com>
 <CALhWmc0qF5stKRcikjwbeFmE-32hNCDazgQdqTMidUyt7u-T1Q@mail.gmail.com>
Message-ID: <CALhWmc0JtQZE5CfLPb1WnwhE9wCYsjE-53kYWbwtFCs1k7FrCQ@mail.gmail.com>

My previous email wasn't sent out.

At first I gave these 3 patches.
ath10k: Add interrupt summary based CE processing
    https://patchwork.kernel.org/patch/11628299/
ath10k: Keep track of which interrupts fired, don't poll them
    https://patchwork.kernel.org/patch/11654631/
ath10k: Get rid of "per_ce_irq" hw param
    https://patchwork.kernel.org/patch/11654633/
and saw the crash happen and then reverted the top 2 and used the very
first one, but it is still happening.

On Mon, Jul 20, 2020 at 5:56 PM Peter Oh <peter.oh at eero.com> wrote:
>
> Since IPQ4019 doesn't support per CE based interrupt summary, I doubt
> if this change is correct.
> +       ath10k_ce_engine_int_status_clear(ar, ctrl_addr,
> +                                         wm_regs->cc_mask | wm_regs->wm_mask);
>
>
> On Mon, Jul 20, 2020 at 5:53 PM Peter Oh <peter.oh at eero.com> wrote:
> >
> > At first I gave these 3 patches.
> > ath10k: Add interrupt summary based CE processing
> >     https://patchwork.kernel.org/patch/11628299/
> > ath10k: Keep track of which interrupts fired, don't poll them
> >     https://patchwork.kernel.org/patch/11654631/
> > ath10k: Get rid of "per_ce_irq" hw param
> >     https://patchwork.kernel.org/patch/11654633/
> > and saw the crash happen and then reverted the top 2 and used the very first one, but it is still happening.
> >
> >
> >
> > On Mon, Jul 20, 2020 at 5:43 PM Peter Oh <peter.oh at eero.com> wrote:
> >>
> >> I've run 3 units and one of them happens the problem always while the
> >> other 2 are barely happening.
> >>
> >> On Mon, Jul 20, 2020 at 5:33 PM Peter Oh <peter.oh at eero.com> wrote:
> >> >
> >> > I'm getting this panic on IPQ4019 system after cherry-picked this
> >> > single patch on top of working system.
> >> >
> >> > [   14.226184] ath10k_ahb a000000.wifi: failed to receive initialized
> >> > event from target: 80000000
> >> > [   14.326406] !#%&PageFault P<find_dr+0x28/0x64>
> >> > L<devres_remove+0x38/0x70> F<005> [00000008]
> >> > [   14.326447] Unable to handle kernel NULL pointer dereference at
> >> > virtual address 00000008
> >> > [   14.333569] pgd = 80cac000
> >> > [   14.341892] [00000008] *pgd=00000000
> >> > [   14.347804] !#%&Abort P<find_dr+0x28/0x64>
> >> > L<devres_remove+0x38/0x70> F<005> FILE<PageFault>
> >> > [   14.348067] Internal error: PageFault: 5 [#1] PREEMPT SMP ARM
> >> > [   14.356568] Modules linked in: ath10k_pci(+) ecm shortcut_fe_drv
> >> > shortcut_fe ath10k_core ath mac80211 cfg80211 compat
> >> > [   14.372537] CPU: 3 PID: 301 Comm: systemd-modules Not tainted
> >> > 4.4.60-yocto-standard-eero #1
> >> > [   14.372805] Hardware name: Qualcomm (Flattened Device Tree)
> >> > [   14.380961] task: 9b492300 ti: 9d3f0000 task.ti: 9d3f0000
> >> > [   14.386516] PC is at find_dr+0x28/0x64
> >> > [   14.392069] LR is at devres_remove+0x38/0x70
> >> > [   14.395720] pc : [<804aa498>]    lr : [<804aa564>]    psr: 00010193
> >> > [   14.395720] sp : 9d3f7cc8  ip : 00000000  fp : 7f18b380
> >> > [   14.400155] r10: 9d995610  r9 : 9b73db64  r8 : 9b740b00
> >> > [   14.411343] r7 : 80430990  r6 : 8043097c  r5 : 9b73da10  r4 : 00000000
> >> > [   14.416554] r3 : 9b740b00  r2 : 8043097c  r1 : 80430990  r0 : 9b73da10
> >> > [   14.423153] Flags: nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM
> >> > Segment user
> >> > [   14.429663] Control: 10c5387d  Table: 80cac06a  DAC: 00000055
> >> > [   14.436865] Process systemd-modules (pid: 301, stack limit = 0x9d3f0210)
> >> > [   14.442683] Stack: (0x9d3f7cc8 to 0x9d3f8000)
> >> > [   14.449455] 7cc0:                   9b73da10 a0010113 80430990
> >> > 8043097c 9b740b00 9b73db60
> >> > [   14.453716] 7ce0: 9d995610 804aa564 9b740b00 9dbd1f20 9d995600
> >> > 9d995600 ffffff92 00000000
> >> > [   14.461876] 7d00: 9d995610 804aac4c 9b740b00 80430a94 9dbd5f20
> >> > 7f28c584 9dbd5f20 7f28cf28
> >> > [   14.470035] 7d20: 7f28f3b2 9dbd1f20 00000001 9cae5960 9d9a16e0
> >> > 00000000 00000000 00000000
> >> > [   14.478196] 7d40: 8162d420 7f28c9d4 9d995610 7f28fb94 8162d42c
> >> > 815a59e0 8162d420 00000003
> >> > [   14.486355] 7d60: 9d3f7f54 804a96cc 9d995610 00000000 7f28fb94
> >> > 804a7df8 7f28fb94 9d995610
> >> > [   14.494516] 7d80: 9d995610 7f28fb94 9d995644 815d8400 00000000
> >> > 0000001c 9cae60c8 804a7f9c
> >> > [   14.502675] 7da0: 00000000 7f28fb94 804a7f50 804a62c0 9d81fc5c
> >> > 9d9f6634 7f28fb94 9b739a00
> >> > [   14.510834] 7dc0: 815a5908 804a7344 7f28f3b2 7f28f3b3 7f28fb94
> >> > 7f293000 00000000 815b6d48
> >> > [   14.518995] 7de0: 815b6d48 804a87a4 9cae61c0 7f293000 00000000
> >> > 7f28d2e8 9cae61c0 7f29300c
> >> > [   14.527153] 7e00: 9cae61c0 80213468 0018bce1 00000001 8040003f
> >> > 802b19d0 9e34ea98 00000000
> >> > [   14.535315] 7e20: 9e34eaa8 9e34ea98 8040003e 9e34e8a0 9e34e8a0
> >> > 9bae8100 9d3f0000 9d801e40
> >> > [   14.543474] 7e40: 00004eb1 9e34e8a0 9bae8080 9d3f0000 81621200
> >> > 7f28fc00 00000001 81599848
> >> > [   14.551632] 7e60: 7f28fc00 00000001 9cae6180 7f28fc48 00000001
> >> > 80287704 7f28fc00 9e34e8a0
> >> > [   14.559793] 7e80: 7f28fc00 00000001 9cae60c0 80289298 7f28fc0c
> >> > 00007fff 7f28fc00 80286a58
> >> > [   14.567952] 7ea0: 00000000 815998c4 a13e1138 7f293100 a13dba30
> >> > 8088bd0c 7f28fdc4 76cea5cc
> >> > [   14.576112] 7ec0: 9d3f7f54 802861d4 00000000 00000000 00000000
> >> > 00000000 00000000 00000000
> >> > [   14.584269] 7ee0: 6e72656b 00006c65 00000000 00000000 00000000
> >> > 00000000 00000000 00000000
> >> > [   14.592430] 7f00: 00000000 00000000 00000000 00000000 00000000
> >> > 00000000 00000000 81599848
> >> > [   14.600590] 7f20: 00000000 00000000 76cea5cc 00000008 0000017b
> >> > 80209de4 9d3f0000 00000000
> >> > [   14.608751] 7f40: 00000000 80289594 9d3f0000 00000000 7e85fbbc
> >> > a13d4000 0000d1b0 a13e0b48
> >> > [   14.616911] 7f60: a13e09ac a13dd590 00007e08 00008ca8 00000000
> >> > 00000000 00000000 0000313c
> >> > [   14.625070] 7f80: 00000026 00000027 0000001d 00000000 00000016
> >> > 00000000 00000000 00000000
> >> > [   14.633230] 7fa0: 5654ca48 80209c40 00000000 00000000 00000008
> >> > 76cea5cc 00000000 00000000
> >> > [   14.641390] 7fc0: 00000000 00000000 5654ca48 0000017b 00000000
> >> > 00000001 76ea754f 00000000
> >> > [   14.649549] 7fe0: 7e85fbc0 7e85fbb0 76ce281c 76c6b830 600f0010
> >> > 00000008 00000000 00000000
> >> > [   14.657717] [<804aa498>] (find_dr) from [<804aa564>]
> >> > (devres_remove+0x38/0x70)
> >> > [   14.665868] [<804aa564>] (devres_remove) from [<804aac4c>]
> >> > (devres_destroy+0x8/0x24)
> >> > [   14.672989] [<804aac4c>] (devres_destroy) from [<80430a94>]
> >> > (devm_iounmap+0x18/0x44)
> >> > [   14.680927] [<80430a94>] (devm_iounmap) from [<7f28c584>]
> >> > (ath10k_ahb_resource_deinit+0x20/0x74 [ath10k_pci])
> >> > [   14.688671] [<7f28c584>] (ath10k_ahb_resource_deinit [ath10k_pci])
> >> > from [<7f28cf28>] (ath10k_ahb_probe+0x554/0x6f4 [ath10k_pci])
> >> > [   14.698454] [<7f28cf28>] (ath10k_ahb_probe [ath10k_pci]) from
> >> > [<804a96cc>] (platform_drv_probe+0x50/0x9c)
> >> > [   14.710061] [<804a96cc>] (platform_drv_probe) from [<804a7df8>]
> >> > (driver_probe_device+0x2ac/0x404)
> >> > [   14.719520] [<804a7df8>] (driver_probe_device) from [<804a7f9c>]
> >> > (__driver_attach+0x4c/0x8c)
> >> > [   14.728374] [<804a7f9c>] (__driver_attach) from [<804a62c0>]
> >> > (bus_for_each_dev+0x7c/0x8c)
> >> > [   14.736880] [<804a62c0>] (bus_for_each_dev) from [<804a7344>]
> >> > (bus_add_driver+0x1b4/0x234)
> >> > [   14.744952] [<804a7344>] (bus_add_driver) from [<804a87a4>]
> >> > (driver_register+0xa0/0xe0)
> >> > [   14.753136] [<804a87a4>] (driver_register) from [<7f28d2e8>]
> >> > (ath10k_ahb_init+0x10/0x38 [ath10k_pci])
> >> > [   14.761061] [<7f28d2e8>] (ath10k_ahb_init [ath10k_pci]) from
> >> > [<7f29300c>] (__init_backport+0xc/0x100 [ath10k_pci])
> >> > [   14.770418] [<7f29300c>] (__init_backport [ath10k_pci]) from
> >> > [<80213468>] (do_one_initcall+0x1c4/0x20c)
> >> > [   14.780633] [<80213468>] (do_one_initcall) from [<80287704>]
> >> > (do_init_module+0x54/0x1ac)
> >> > [   14.789916] [<80287704>] (do_init_module) from [<80289298>]
> >> > (load_module+0x19e0/0x1b04)
> >> > [   14.798249] [<80289298>] (load_module) from [<80289594>]
> >> > (SyS_finit_module+0x8c/0x9c)
> >> > [   14.805975] [<80289594>] (SyS_finit_module) from [<80209c40>]
> >> > (ret_fast_syscall+0x0/0x34)
> >> > [   14.813959] Code: e1a08003 e1540009 03a04000 0a00000c (e5943008)
> >> > [   14.822108] ---[ end trace f4da008c1c165fb3 ]---
> >> > [   14.830623] Kernel panic - not syncing: Fatal exception
> >> > [   14.832876] CPU1: stopping
> >> > [   14.837820] CPU: 1 PID: 343 Comm: rngd Tainted: G      D
> >> > 4.4.60-yocto-standard-eero #1
> >> > [   14.840601] Hardware name: Qualcomm (Flattened Device Tree)
> >> > [   14.849210] [<8021ed7c>] (unwind_backtrace) from [<8021b730>]
> >> > (show_stack+0x10/0x14)
> >> > [   14.854672] [<8021b730>] (show_stack) from [<8041b8dc>]
> >> > (dump_stack+0x7c/0x98)
> >> > [   14.862658] [<8041b8dc>] (dump_stack) from [<8021dfc8>]
> >> > (handle_IPI+0xdc/0x164)
> >> > [   14.869688] [<8021dfc8>] (handle_IPI) from [<802093e8>]
> >> > (gic_handle_irq+0x80/0x8c)
> >> > [   14.876893] [<802093e8>] (gic_handle_irq) from [<8020a844>]
> >> > (__irq_usr+0x44/0x60)
> >> > [   14.884524] Exception stack(0x9beaffb0 to 0x9beafff8)
> >> > [   14.892076] ffa0:                                     0c27987c
> >> > 40016b9f 0c27987d 0000001f
> >> > [   14.897118] ffc0: 00000001 763fedbc 565a344c 54b3de80 54b3e50c
> >> > 00000001 7e817c00 763fed0c
> >> > [   14.905277] ffe0: fffffffe 763fecc0 00000018 76ec3e18 30010010 ffffffff
> >> > [   14.913430] CPU2: stopping
> >> > [   14.919849] CPU: 2 PID: 344 Comm: rngd Tainted: G      D
> >> > 4.4.60-yocto-standard-eero #1
> >> > [   14.922631] Hardware name: Qualcomm (Flattened Device Tree)
> >> > [   14.931236] [<8021ed7c>] (unwind_backtrace) from [<8021b730>]
> >> > (show_stack+0x10/0x14)
> >> > [   14.936703] [<8021b730>] (show_stack) from [<8041b8dc>]
> >> > (dump_stack+0x7c/0x98)
> >> > [   14.944688] [<8041b8dc>] (dump_stack) from [<8021dfc8>]
> >> > (handle_IPI+0xdc/0x164)
> >> > [   14.951719] [<8021dfc8>] (handle_IPI) from [<802093e8>]
> >> > (gic_handle_irq+0x80/0x8c)
> >> > [   14.958924] [<802093e8>] (gic_handle_irq) from [<8020a844>]
> >> > (__irq_usr+0x44/0x60)
> >> > [   14.966554] Exception stack(0x9beb7fb0 to 0x9beb7ff8)
> >> > [   14.974107] 7fa0:                                     fffffff7
> >> > 00000017 a6000000 0000014a
> >> > [   14.979150] 7fc0: 00000002 759fedbc 565a3470 54b3de80 54b3e50c
> >> > 00000001 7e817c00 759fed0c
> >> > [   14.987307] 7fe0: 00000009 759fecc0 00000018 76ec3cdc 80010010 ffffffff
> >> > [   14.995461] CPU0: stopping
> >> > [   15.001882] CPU: 0 PID: 341 Comm: rngd Tainted: G      D
> >> > 4.4.60-yocto-standard-eero #1
> >> > [   15.004663] Hardware name: Qualcomm (Flattened Device Tree)
> >> > [   15.013267] [<8021ed7c>] (unwind_backtrace) from [<8021b730>]
> >> > (show_stack+0x10/0x14)
> >> > [   15.018734] [<8021b730>] (show_stack) from [<8041b8dc>]
> >> > (dump_stack+0x7c/0x98)
> >> > [   15.026719] [<8041b8dc>] (dump_stack) from [<8021dfc8>]
> >> > (handle_IPI+0xdc/0x164)
> >> > [   15.033752] [<8021dfc8>] (handle_IPI) from [<802093e8>]
> >> > (gic_handle_irq+0x80/0x8c)
> >> > [   15.040955] [<802093e8>] (gic_handle_irq) from [<8020a844>]
> >> > (__irq_usr+0x44/0x60)
> >> > [   15.048585] Exception stack(0x9be87fb0 to 0x9be87ff8)
> >> > [   15.056139] 7fa0:                                     00000000
> >> > 00000000 a7e3391d 6a11d866
> >> > [   15.061181] 7fc0: 00000000 76d15dbc 565a3428 54b3de80 54b3e50c
> >> > 00000001 7e817c00 76d15d0c
> >> > [   15.069339] 7fe0: ffffffeb 76d15cc0 00000018 76ec3d60 80010010 ffffffff
> >> > [   15.091080] Rebooting in 5 seconds..
> >> >
> >> >
> >> > On Wed, Jul 15, 2020 at 11:39 PM Kalle Valo <kvalo at codeaurora.org> wrote:
> >> > >
> >> > > Brian Norris <briannorris at chromium.org> writes:
> >> > >
> >> > > > On Fri, Jun 26, 2020 at 2:49 PM Doug Anderson <dianders at chromium.org> wrote:
> >> > > >> I should also note that, while I'm not terribly familiar with Kalle's
> >> > > >> workflow, I would have expected to see him in the "To:" list.  I've
> >> > > >> added him, but it's possible he'll need you to repost the patch with
> >> > > >> him in the "To:" list.
> >> > > >
> >> > > > https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#who_to_address
> >> > > > https://wireless.wiki.kernel.org/en/users/drivers/ath10k/submittingpatches
> >> > > >
> >> > > > Patchwork is his patch queue, so I don't think you need to address him directly.
> >> > >
> >> > > Yup, I take all patches from patchwork so no need to Cc me.
> >> > >
> >> > > --
> >> > > https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


From peter.oh at eero.com  Mon Jul 20 21:32:35 2020
From: peter.oh at eero.com (Peter Oh)
Date: Mon, 20 Jul 2020 18:32:35 -0700
Subject: [PATCH] ath10k: Add interrupt summary based CE processing
In-Reply-To: <CALhWmc0JtQZE5CfLPb1WnwhE9wCYsjE-53kYWbwtFCs1k7FrCQ@mail.gmail.com>
References: <1593193967-29897-1-git-send-email-pillair@codeaurora.org>
 <CAD=FV=V_ynwukeR92nbJXkuQ7OAW4mLaTjxko7fXt5aEfDUNhA@mail.gmail.com>
 <CAD=FV=XJDmGbEJQ1U-VDuN2p0+V+uRm_1=DwBnDPmPQsXqS4ZA@mail.gmail.com>
 <CA+ASDXNOCFZhdNMDk9XTuC2H+owQ0+wHipDbkJAGnU9q7BXz_w@mail.gmail.com>
 <871rlcx8uv.fsf@codeaurora.org>
 <CALhWmc1PbTKhrkaPn9yfpx3gZHAMuR-bPY=4_o4wQHv_H5D9dA@mail.gmail.com>
 <CALhWmc3i9Z+KiG1cJNvpSWNsiFhOa5jBw=XfcFz_gKwi_5QibA@mail.gmail.com>
 <CALhWmc1B0+SONV6_AF+nUzgxZdekPD3sZuhrsmwVQx1Q-cgT_g@mail.gmail.com>
 <CALhWmc0qF5stKRcikjwbeFmE-32hNCDazgQdqTMidUyt7u-T1Q@mail.gmail.com>
 <CALhWmc0JtQZE5CfLPb1WnwhE9wCYsjE-53kYWbwtFCs1k7FrCQ@mail.gmail.com>
Message-ID: <CALhWmc11OefTh6Ov5GqP-yHMVTUO4r9CxqkdHT1F3yzor72v7g@mail.gmail.com>

I'll take my word back.
It's not this patch problem, but by others.
I have 2 extra patches before the 3 patches so my system looks like

backports from ath.git 5.6-rc1 + linux kernel 4.4 (similar to OpenWrt)
On top of the working system, I cherry-picked these 5.

#1.
ath10k: Avoid override CE5 configuration for QCA99X0 chipsets
ath.git commit 521fc37be3d879561ca5ab42d64719cf94116af0
#2.
ath10k: Fix NULL pointer dereference in AHB device probe
wireless-drivers.git commit 1cfd3426ef989b83fa6176490a38777057e57f6c
#3.
ath10k: Add interrupt summary based CE processing
https://patchwork.kernel.org/patch/11628299/
#4.
ath10k: Keep track of which interrupts fired, don't poll them
https://patchwork.kernel.org/patch/11654631/
#5.
ath10k: Get rid of "per_ce_irq" hw param
https://patchwork.kernel.org/patch/11654633/

The error "[  14.226184] ath10k_ahb a000000.wifi: failed to receive
initialized event from target: 80000000" is because of #1 and #2,
since this happens even after I reverted #3~#5.
Once I reverted all except #1 I got another crash.

[   11.179595] !#%&PageFault P<__ath10k_ce_rx_post_buf+0x14/0x98
[ath10k_core]> L<0x4bc00> F<005> [0000000c]
[   11.179643] Unable to handle kernel NULL pointer dereference at
virtual address 0000000c
[   11.439207] [<7f15a69c>] (__ath10k_ce_rx_post_buf [ath10k_core])
from [<7f15a874>] (ath10k_ce_rx_post_buf+0x3c/0x50 [ath10k_core])
[   11.447204] [<7f15a874>] (ath10k_ce_rx_post_buf [ath10k_core]) from
[<7f2889a4>] (ath10k_pci_diag_read_mem+0x104/0x2a8 [ath10k_pci])
[   11.458706] [<7f2889a4>] (ath10k_pci_diag_read_mem [ath10k_pci])
from [<7f288b68>] (ath10k_pci_diag_read32+0x1c/0x2c [ath10k_pci])
[   11.470767] [<7f288b68>] (ath10k_pci_diag_read32 [ath10k_pci]) from
[<7f28abe8>] (ath10k_pci_init_config+0x2c/0x290 [ath10k_pci])
[   11.482314] [<7f28abe8>] (ath10k_pci_init_config [ath10k_pci]) from
[<7f28d160>] (ath10k_ahb_hif_power_up+0x7c/0xe8 [ath10k_pci])
[   11.494153] [<7f28d160>] (ath10k_ahb_hif_power_up [ath10k_pci])
from [<7f135348>] (ath10k_core_register_work+0x84/0x8f8 [ath10k_core])
[   11.505766] [<7f135348>] (ath10k_core_register_work [ath10k_core])
from [<8023b614>] (process_one_work+0x1c0/0x2f8)
[   11.517594] [<8023b614>] (process_one_work) from [<8023c650>]
(worker_thread+0x280/0x3c0)
[   11.527919] [<8023c650>] (worker_thread) from [<802408f8>]
(kthread+0xd8/0xe8)
[   11.536247] [<802408f8>] (kthread) from [<80209ce8>]
(ret_from_fork+0x14/0x2c)

When I revert #1 eventually, my system is back to working.
So I'm blaming the #1 and #2 could have potential bugs or require
ath.git branch up-to-date.

On Mon, Jul 20, 2020 at 5:58 PM Peter Oh <peter.oh at eero.com> wrote:
>
> My previous email wasn't sent out.
>
> At first I gave these 3 patches.
> ath10k: Add interrupt summary based CE processing
>     https://patchwork.kernel.org/patch/11628299/
> ath10k: Keep track of which interrupts fired, don't poll them
>     https://patchwork.kernel.org/patch/11654631/
> ath10k: Get rid of "per_ce_irq" hw param
>     https://patchwork.kernel.org/patch/11654633/
> and saw the crash happen and then reverted the top 2 and used the very
> first one, but it is still happening.
>
> On Mon, Jul 20, 2020 at 5:56 PM Peter Oh <peter.oh at eero.com> wrote:
> >
> > Since IPQ4019 doesn't support per CE based interrupt summary, I doubt
> > if this change is correct.
> > +       ath10k_ce_engine_int_status_clear(ar, ctrl_addr,
> > +                                         wm_regs->cc_mask | wm_regs->wm_mask);
> >
> >
> > On Mon, Jul 20, 2020 at 5:53 PM Peter Oh <peter.oh at eero.com> wrote:
> > >
> > > At first I gave these 3 patches.
> > > ath10k: Add interrupt summary based CE processing
> > >     https://patchwork.kernel.org/patch/11628299/
> > > ath10k: Keep track of which interrupts fired, don't poll them
> > >     https://patchwork.kernel.org/patch/11654631/
> > > ath10k: Get rid of "per_ce_irq" hw param
> > >     https://patchwork.kernel.org/patch/11654633/
> > > and saw the crash happen and then reverted the top 2 and used the very first one, but it is still happening.
> > >
> > >
> > >
> > > On Mon, Jul 20, 2020 at 5:43 PM Peter Oh <peter.oh at eero.com> wrote:
> > >>
> > >> I've run 3 units and one of them happens the problem always while the
> > >> other 2 are barely happening.
> > >>
> > >> On Mon, Jul 20, 2020 at 5:33 PM Peter Oh <peter.oh at eero.com> wrote:
> > >> >
> > >> > I'm getting this panic on IPQ4019 system after cherry-picked this
> > >> > single patch on top of working system.
> > >> >
> > >> > [   14.226184] ath10k_ahb a000000.wifi: failed to receive initialized
> > >> > event from target: 80000000
> > >> > [   14.326406] !#%&PageFault P<find_dr+0x28/0x64>
> > >> > L<devres_remove+0x38/0x70> F<005> [00000008]
> > >> > [   14.326447] Unable to handle kernel NULL pointer dereference at
> > >> > virtual address 00000008
> > >> > [   14.333569] pgd = 80cac000
> > >> > [   14.341892] [00000008] *pgd=00000000
> > >> > [   14.347804] !#%&Abort P<find_dr+0x28/0x64>
> > >> > L<devres_remove+0x38/0x70> F<005> FILE<PageFault>
> > >> > [   14.348067] Internal error: PageFault: 5 [#1] PREEMPT SMP ARM
> > >> > [   14.356568] Modules linked in: ath10k_pci(+) ecm shortcut_fe_drv
> > >> > shortcut_fe ath10k_core ath mac80211 cfg80211 compat
> > >> > [   14.372537] CPU: 3 PID: 301 Comm: systemd-modules Not tainted
> > >> > 4.4.60-yocto-standard-eero #1
> > >> > [   14.372805] Hardware name: Qualcomm (Flattened Device Tree)
> > >> > [   14.380961] task: 9b492300 ti: 9d3f0000 task.ti: 9d3f0000
> > >> > [   14.386516] PC is at find_dr+0x28/0x64
> > >> > [   14.392069] LR is at devres_remove+0x38/0x70
> > >> > [   14.395720] pc : [<804aa498>]    lr : [<804aa564>]    psr: 00010193
> > >> > [   14.395720] sp : 9d3f7cc8  ip : 00000000  fp : 7f18b380
> > >> > [   14.400155] r10: 9d995610  r9 : 9b73db64  r8 : 9b740b00
> > >> > [   14.411343] r7 : 80430990  r6 : 8043097c  r5 : 9b73da10  r4 : 00000000
> > >> > [   14.416554] r3 : 9b740b00  r2 : 8043097c  r1 : 80430990  r0 : 9b73da10
> > >> > [   14.423153] Flags: nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM
> > >> > Segment user
> > >> > [   14.429663] Control: 10c5387d  Table: 80cac06a  DAC: 00000055
> > >> > [   14.436865] Process systemd-modules (pid: 301, stack limit = 0x9d3f0210)
> > >> > [   14.442683] Stack: (0x9d3f7cc8 to 0x9d3f8000)
> > >> > [   14.449455] 7cc0:                   9b73da10 a0010113 80430990
> > >> > 8043097c 9b740b00 9b73db60
> > >> > [   14.453716] 7ce0: 9d995610 804aa564 9b740b00 9dbd1f20 9d995600
> > >> > 9d995600 ffffff92 00000000
> > >> > [   14.461876] 7d00: 9d995610 804aac4c 9b740b00 80430a94 9dbd5f20
> > >> > 7f28c584 9dbd5f20 7f28cf28
> > >> > [   14.470035] 7d20: 7f28f3b2 9dbd1f20 00000001 9cae5960 9d9a16e0
> > >> > 00000000 00000000 00000000
> > >> > [   14.478196] 7d40: 8162d420 7f28c9d4 9d995610 7f28fb94 8162d42c
> > >> > 815a59e0 8162d420 00000003
> > >> > [   14.486355] 7d60: 9d3f7f54 804a96cc 9d995610 00000000 7f28fb94
> > >> > 804a7df8 7f28fb94 9d995610
> > >> > [   14.494516] 7d80: 9d995610 7f28fb94 9d995644 815d8400 00000000
> > >> > 0000001c 9cae60c8 804a7f9c
> > >> > [   14.502675] 7da0: 00000000 7f28fb94 804a7f50 804a62c0 9d81fc5c
> > >> > 9d9f6634 7f28fb94 9b739a00
> > >> > [   14.510834] 7dc0: 815a5908 804a7344 7f28f3b2 7f28f3b3 7f28fb94
> > >> > 7f293000 00000000 815b6d48
> > >> > [   14.518995] 7de0: 815b6d48 804a87a4 9cae61c0 7f293000 00000000
> > >> > 7f28d2e8 9cae61c0 7f29300c
> > >> > [   14.527153] 7e00: 9cae61c0 80213468 0018bce1 00000001 8040003f
> > >> > 802b19d0 9e34ea98 00000000
> > >> > [   14.535315] 7e20: 9e34eaa8 9e34ea98 8040003e 9e34e8a0 9e34e8a0
> > >> > 9bae8100 9d3f0000 9d801e40
> > >> > [   14.543474] 7e40: 00004eb1 9e34e8a0 9bae8080 9d3f0000 81621200
> > >> > 7f28fc00 00000001 81599848
> > >> > [   14.551632] 7e60: 7f28fc00 00000001 9cae6180 7f28fc48 00000001
> > >> > 80287704 7f28fc00 9e34e8a0
> > >> > [   14.559793] 7e80: 7f28fc00 00000001 9cae60c0 80289298 7f28fc0c
> > >> > 00007fff 7f28fc00 80286a58
> > >> > [   14.567952] 7ea0: 00000000 815998c4 a13e1138 7f293100 a13dba30
> > >> > 8088bd0c 7f28fdc4 76cea5cc
> > >> > [   14.576112] 7ec0: 9d3f7f54 802861d4 00000000 00000000 00000000
> > >> > 00000000 00000000 00000000
> > >> > [   14.584269] 7ee0: 6e72656b 00006c65 00000000 00000000 00000000
> > >> > 00000000 00000000 00000000
> > >> > [   14.592430] 7f00: 00000000 00000000 00000000 00000000 00000000
> > >> > 00000000 00000000 81599848
> > >> > [   14.600590] 7f20: 00000000 00000000 76cea5cc 00000008 0000017b
> > >> > 80209de4 9d3f0000 00000000
> > >> > [   14.608751] 7f40: 00000000 80289594 9d3f0000 00000000 7e85fbbc
> > >> > a13d4000 0000d1b0 a13e0b48
> > >> > [   14.616911] 7f60: a13e09ac a13dd590 00007e08 00008ca8 00000000
> > >> > 00000000 00000000 0000313c
> > >> > [   14.625070] 7f80: 00000026 00000027 0000001d 00000000 00000016
> > >> > 00000000 00000000 00000000
> > >> > [   14.633230] 7fa0: 5654ca48 80209c40 00000000 00000000 00000008
> > >> > 76cea5cc 00000000 00000000
> > >> > [   14.641390] 7fc0: 00000000 00000000 5654ca48 0000017b 00000000
> > >> > 00000001 76ea754f 00000000
> > >> > [   14.649549] 7fe0: 7e85fbc0 7e85fbb0 76ce281c 76c6b830 600f0010
> > >> > 00000008 00000000 00000000
> > >> > [   14.657717] [<804aa498>] (find_dr) from [<804aa564>]
> > >> > (devres_remove+0x38/0x70)
> > >> > [   14.665868] [<804aa564>] (devres_remove) from [<804aac4c>]
> > >> > (devres_destroy+0x8/0x24)
> > >> > [   14.672989] [<804aac4c>] (devres_destroy) from [<80430a94>]
> > >> > (devm_iounmap+0x18/0x44)
> > >> > [   14.680927] [<80430a94>] (devm_iounmap) from [<7f28c584>]
> > >> > (ath10k_ahb_resource_deinit+0x20/0x74 [ath10k_pci])
> > >> > [   14.688671] [<7f28c584>] (ath10k_ahb_resource_deinit [ath10k_pci])
> > >> > from [<7f28cf28>] (ath10k_ahb_probe+0x554/0x6f4 [ath10k_pci])
> > >> > [   14.698454] [<7f28cf28>] (ath10k_ahb_probe [ath10k_pci]) from
> > >> > [<804a96cc>] (platform_drv_probe+0x50/0x9c)
> > >> > [   14.710061] [<804a96cc>] (platform_drv_probe) from [<804a7df8>]
> > >> > (driver_probe_device+0x2ac/0x404)
> > >> > [   14.719520] [<804a7df8>] (driver_probe_device) from [<804a7f9c>]
> > >> > (__driver_attach+0x4c/0x8c)
> > >> > [   14.728374] [<804a7f9c>] (__driver_attach) from [<804a62c0>]
> > >> > (bus_for_each_dev+0x7c/0x8c)
> > >> > [   14.736880] [<804a62c0>] (bus_for_each_dev) from [<804a7344>]
> > >> > (bus_add_driver+0x1b4/0x234)
> > >> > [   14.744952] [<804a7344>] (bus_add_driver) from [<804a87a4>]
> > >> > (driver_register+0xa0/0xe0)
> > >> > [   14.753136] [<804a87a4>] (driver_register) from [<7f28d2e8>]
> > >> > (ath10k_ahb_init+0x10/0x38 [ath10k_pci])
> > >> > [   14.761061] [<7f28d2e8>] (ath10k_ahb_init [ath10k_pci]) from
> > >> > [<7f29300c>] (__init_backport+0xc/0x100 [ath10k_pci])
> > >> > [   14.770418] [<7f29300c>] (__init_backport [ath10k_pci]) from
> > >> > [<80213468>] (do_one_initcall+0x1c4/0x20c)
> > >> > [   14.780633] [<80213468>] (do_one_initcall) from [<80287704>]
> > >> > (do_init_module+0x54/0x1ac)
> > >> > [   14.789916] [<80287704>] (do_init_module) from [<80289298>]
> > >> > (load_module+0x19e0/0x1b04)
> > >> > [   14.798249] [<80289298>] (load_module) from [<80289594>]
> > >> > (SyS_finit_module+0x8c/0x9c)
> > >> > [   14.805975] [<80289594>] (SyS_finit_module) from [<80209c40>]
> > >> > (ret_fast_syscall+0x0/0x34)
> > >> > [   14.813959] Code: e1a08003 e1540009 03a04000 0a00000c (e5943008)
> > >> > [   14.822108] ---[ end trace f4da008c1c165fb3 ]---
> > >> > [   14.830623] Kernel panic - not syncing: Fatal exception
> > >> > [   14.832876] CPU1: stopping
> > >> > [   14.837820] CPU: 1 PID: 343 Comm: rngd Tainted: G      D
> > >> > 4.4.60-yocto-standard-eero #1
> > >> > [   14.840601] Hardware name: Qualcomm (Flattened Device Tree)
> > >> > [   14.849210] [<8021ed7c>] (unwind_backtrace) from [<8021b730>]
> > >> > (show_stack+0x10/0x14)
> > >> > [   14.854672] [<8021b730>] (show_stack) from [<8041b8dc>]
> > >> > (dump_stack+0x7c/0x98)
> > >> > [   14.862658] [<8041b8dc>] (dump_stack) from [<8021dfc8>]
> > >> > (handle_IPI+0xdc/0x164)
> > >> > [   14.869688] [<8021dfc8>] (handle_IPI) from [<802093e8>]
> > >> > (gic_handle_irq+0x80/0x8c)
> > >> > [   14.876893] [<802093e8>] (gic_handle_irq) from [<8020a844>]
> > >> > (__irq_usr+0x44/0x60)
> > >> > [   14.884524] Exception stack(0x9beaffb0 to 0x9beafff8)
> > >> > [   14.892076] ffa0:                                     0c27987c
> > >> > 40016b9f 0c27987d 0000001f
> > >> > [   14.897118] ffc0: 00000001 763fedbc 565a344c 54b3de80 54b3e50c
> > >> > 00000001 7e817c00 763fed0c
> > >> > [   14.905277] ffe0: fffffffe 763fecc0 00000018 76ec3e18 30010010 ffffffff
> > >> > [   14.913430] CPU2: stopping
> > >> > [   14.919849] CPU: 2 PID: 344 Comm: rngd Tainted: G      D
> > >> > 4.4.60-yocto-standard-eero #1
> > >> > [   14.922631] Hardware name: Qualcomm (Flattened Device Tree)
> > >> > [   14.931236] [<8021ed7c>] (unwind_backtrace) from [<8021b730>]
> > >> > (show_stack+0x10/0x14)
> > >> > [   14.936703] [<8021b730>] (show_stack) from [<8041b8dc>]
> > >> > (dump_stack+0x7c/0x98)
> > >> > [   14.944688] [<8041b8dc>] (dump_stack) from [<8021dfc8>]
> > >> > (handle_IPI+0xdc/0x164)
> > >> > [   14.951719] [<8021dfc8>] (handle_IPI) from [<802093e8>]
> > >> > (gic_handle_irq+0x80/0x8c)
> > >> > [   14.958924] [<802093e8>] (gic_handle_irq) from [<8020a844>]
> > >> > (__irq_usr+0x44/0x60)
> > >> > [   14.966554] Exception stack(0x9beb7fb0 to 0x9beb7ff8)
> > >> > [   14.974107] 7fa0:                                     fffffff7
> > >> > 00000017 a6000000 0000014a
> > >> > [   14.979150] 7fc0: 00000002 759fedbc 565a3470 54b3de80 54b3e50c
> > >> > 00000001 7e817c00 759fed0c
> > >> > [   14.987307] 7fe0: 00000009 759fecc0 00000018 76ec3cdc 80010010 ffffffff
> > >> > [   14.995461] CPU0: stopping
> > >> > [   15.001882] CPU: 0 PID: 341 Comm: rngd Tainted: G      D
> > >> > 4.4.60-yocto-standard-eero #1
> > >> > [   15.004663] Hardware name: Qualcomm (Flattened Device Tree)
> > >> > [   15.013267] [<8021ed7c>] (unwind_backtrace) from [<8021b730>]
> > >> > (show_stack+0x10/0x14)
> > >> > [   15.018734] [<8021b730>] (show_stack) from [<8041b8dc>]
> > >> > (dump_stack+0x7c/0x98)
> > >> > [   15.026719] [<8041b8dc>] (dump_stack) from [<8021dfc8>]
> > >> > (handle_IPI+0xdc/0x164)
> > >> > [   15.033752] [<8021dfc8>] (handle_IPI) from [<802093e8>]
> > >> > (gic_handle_irq+0x80/0x8c)
> > >> > [   15.040955] [<802093e8>] (gic_handle_irq) from [<8020a844>]
> > >> > (__irq_usr+0x44/0x60)
> > >> > [   15.048585] Exception stack(0x9be87fb0 to 0x9be87ff8)
> > >> > [   15.056139] 7fa0:                                     00000000
> > >> > 00000000 a7e3391d 6a11d866
> > >> > [   15.061181] 7fc0: 00000000 76d15dbc 565a3428 54b3de80 54b3e50c
> > >> > 00000001 7e817c00 76d15d0c
> > >> > [   15.069339] 7fe0: ffffffeb 76d15cc0 00000018 76ec3d60 80010010 ffffffff
> > >> > [   15.091080] Rebooting in 5 seconds..
> > >> >
> > >> >
> > >> > On Wed, Jul 15, 2020 at 11:39 PM Kalle Valo <kvalo at codeaurora.org> wrote:
> > >> > >
> > >> > > Brian Norris <briannorris at chromium.org> writes:
> > >> > >
> > >> > > > On Fri, Jun 26, 2020 at 2:49 PM Doug Anderson <dianders at chromium.org> wrote:
> > >> > > >> I should also note that, while I'm not terribly familiar with Kalle's
> > >> > > >> workflow, I would have expected to see him in the "To:" list.  I've
> > >> > > >> added him, but it's possible he'll need you to repost the patch with
> > >> > > >> him in the "To:" list.
> > >> > > >
> > >> > > > https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#who_to_address
> > >> > > > https://wireless.wiki.kernel.org/en/users/drivers/ath10k/submittingpatches
> > >> > > >
> > >> > > > Patchwork is his patch queue, so I don't think you need to address him directly.
> > >> > >
> > >> > > Yup, I take all patches from patchwork so no need to Cc me.
> > >> > >
> > >> > > --
> > >> > > https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


From lkp at intel.com  Tue Jul 21 03:05:27 2020
From: lkp at intel.com (kernel test robot)
Date: Tue, 21 Jul 2020 15:05:27 +0800
Subject: [ath6kl:ath-next] BUILD SUCCESS
 bad60b8d1a7194df38fd7fe4b22f3f4dcf775099
Message-ID: <5f1693b7.usXi8SsgdhEHf/sZ%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git  ath-next
branch HEAD: bad60b8d1a7194df38fd7fe4b22f3f4dcf775099  ath10k: check idx validity in __ath10k_htt_rx_ring_fill_n()

elapsed time: 735m

configs tested: 117
configs skipped: 4

The following configs have been built successfully.
More configs may be tested in the coming days.

arm                                 defconfig
arm                              allyesconfig
arm                              allmodconfig
arm                               allnoconfig
arm64                            allyesconfig
arm64                               defconfig
arm64                            allmodconfig
arm64                             allnoconfig
c6x                                 defconfig
c6x                        evmc6474_defconfig
arm                     eseries_pxa_defconfig
arc                         haps_hs_defconfig
arm                        realview_defconfig
arm                          lpd270_defconfig
c6x                         dsk6455_defconfig
m68k                         amcore_defconfig
arm                          simpad_defconfig
openrisc                         allyesconfig
mips                   sb1250_swarm_defconfig
arm                         shannon_defconfig
arm                      footbridge_defconfig
s390                             alldefconfig
c6x                               allnoconfig
sparc64                           allnoconfig
powerpc                       ppc64_defconfig
s390                          debug_defconfig
arm                          pxa3xx_defconfig
m68k                        m5407c3_defconfig
sh                          sdk7780_defconfig
arm                           h5000_defconfig
i386                                defconfig
i386                              debian-10.3
i386                              allnoconfig
i386                             allyesconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                              allnoconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                              allnoconfig
m68k                           sun3_defconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
nios2                            allyesconfig
openrisc                            defconfig
c6x                              allyesconfig
nds32                               defconfig
nds32                             allnoconfig
csky                             allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
h8300                            allmodconfig
xtensa                              defconfig
arc                                 defconfig
arc                              allyesconfig
sh                               allmodconfig
sh                                allnoconfig
microblaze                        allnoconfig
mips                             allyesconfig
mips                              allnoconfig
mips                             allmodconfig
parisc                            allnoconfig
parisc                              defconfig
parisc                           allyesconfig
parisc                           allmodconfig
powerpc                             defconfig
powerpc                          allyesconfig
powerpc                          rhel-kconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
i386                 randconfig-a001-20200719
i386                 randconfig-a006-20200719
i386                 randconfig-a002-20200719
i386                 randconfig-a005-20200719
i386                 randconfig-a003-20200719
i386                 randconfig-a004-20200719
x86_64               randconfig-a014-20200720
x86_64               randconfig-a015-20200720
x86_64               randconfig-a016-20200720
x86_64               randconfig-a012-20200720
x86_64               randconfig-a013-20200720
x86_64               randconfig-a011-20200720
x86_64               randconfig-a005-20200719
x86_64               randconfig-a002-20200719
x86_64               randconfig-a006-20200719
x86_64               randconfig-a001-20200719
x86_64               randconfig-a003-20200719
x86_64               randconfig-a004-20200719
i386                 randconfig-a015-20200719
i386                 randconfig-a011-20200719
i386                 randconfig-a016-20200719
i386                 randconfig-a012-20200719
i386                 randconfig-a013-20200719
i386                 randconfig-a014-20200719
riscv                            allyesconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                            allmodconfig
s390                             allyesconfig
s390                              allnoconfig
s390                             allmodconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
sparc64                             defconfig
sparc64                          allyesconfig
sparc64                          allmodconfig
x86_64                    rhel-7.6-kselftests
x86_64                               rhel-8.3
x86_64                                  kexec
x86_64                                   rhel
x86_64                                    lkp
x86_64                              fedora-25

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From pillair at codeaurora.org  Tue Jul 21 07:24:30 2020
From: pillair at codeaurora.org (Rakesh Pillai)
Date: Tue, 21 Jul 2020 16:54:30 +0530
Subject: [PATCH] ath10k: Add interrupt summary based CE processing
In-Reply-To: <CALhWmc11OefTh6Ov5GqP-yHMVTUO4r9CxqkdHT1F3yzor72v7g@mail.gmail.com>
References: <1593193967-29897-1-git-send-email-pillair@codeaurora.org>
 <CAD=FV=V_ynwukeR92nbJXkuQ7OAW4mLaTjxko7fXt5aEfDUNhA@mail.gmail.com>
 <CAD=FV=XJDmGbEJQ1U-VDuN2p0+V+uRm_1=DwBnDPmPQsXqS4ZA@mail.gmail.com>
 <CA+ASDXNOCFZhdNMDk9XTuC2H+owQ0+wHipDbkJAGnU9q7BXz_w@mail.gmail.com>
 <871rlcx8uv.fsf@codeaurora.org>
 <CALhWmc1PbTKhrkaPn9yfpx3gZHAMuR-bPY=4_o4wQHv_H5D9dA@mail.gmail.com>
 <CALhWmc3i9Z+KiG1cJNvpSWNsiFhOa5jBw=XfcFz_gKwi_5QibA@mail.gmail.com>
 <CALhWmc1B0+SONV6_AF+nUzgxZdekPD3sZuhrsmwVQx1Q-cgT_g@mail.gmail.com>
 <CALhWmc0qF5stKRcikjwbeFmE-32hNCDazgQdqTMidUyt7u-T1Q@mail.gmail.com>
 <CALhWmc0JtQZE5CfLPb1WnwhE9wCYsjE-53kYWbwtFCs1k7FrCQ@mail.gmail.com>
 <CALhWmc11OefTh6Ov5GqP-yHMVTUO4r9CxqkdHT1F3yzor72v7g@mail.gmail.com>
Message-ID: <000201d65f51$83d2ac60$8b780520$@codeaurora.org>



> -----Original Message-----
> From: Peter Oh <peter.oh at eero.com>
> Sent: Tuesday, July 21, 2020 7:03 AM
> To: Kalle Valo <kvalo at codeaurora.org>
> Cc: Brian Norris <briannorris at chromium.org>; Doug Anderson
> <dianders at chromium.org>; linux-wireless <linux-
> wireless at vger.kernel.org>; Rakesh Pillai <pillair at codeaurora.org>; ath10k
> <ath10k at lists.infradead.org>; LKML <linux-kernel at vger.kernel.org>
> Subject: Re: [PATCH] ath10k: Add interrupt summary based CE processing
> 
> I'll take my word back.
> It's not this patch problem, but by others.
> I have 2 extra patches before the 3 patches so my system looks like
> 
> backports from ath.git 5.6-rc1 + linux kernel 4.4 (similar to OpenWrt)
> On top of the working system, I cherry-picked these 5.
> 
> #1.
> ath10k: Avoid override CE5 configuration for QCA99X0 chipsets
> ath.git commit 521fc37be3d879561ca5ab42d64719cf94116af0
> #2.
> ath10k: Fix NULL pointer dereference in AHB device probe
> wireless-drivers.git commit 1cfd3426ef989b83fa6176490a38777057e57f6c
> #3.
> ath10k: Add interrupt summary based CE processing
> https://patchwork.kernel.org/patch/11628299/

Hi Peter,
This patch is applicable only for snoc target WCN3990, since there is a check for per_ce_irq.
For PCI targets, per_ce_irq is false, and hence follows a different path.

Thanks,
Rakesh Pillai.



> #4.
> ath10k: Keep track of which interrupts fired, don't poll them
> https://patchwork.kernel.org/patch/11654631/
> #5.
> ath10k: Get rid of "per_ce_irq" hw param
> https://patchwork.kernel.org/patch/11654633/
> 
> The error "[  14.226184] ath10k_ahb a000000.wifi: failed to receive
> initialized event from target: 80000000" is because of #1 and #2,
> since this happens even after I reverted #3~#5.
> Once I reverted all except #1 I got another crash.
> 
> [   11.179595] !#%&PageFault P<__ath10k_ce_rx_post_buf+0x14/0x98
> [ath10k_core]> L<0x4bc00> F<005> [0000000c]
> [   11.179643] Unable to handle kernel NULL pointer dereference at
> virtual address 0000000c
> [   11.439207] [<7f15a69c>] (__ath10k_ce_rx_post_buf [ath10k_core])
> from [<7f15a874>] (ath10k_ce_rx_post_buf+0x3c/0x50 [ath10k_core])
> [   11.447204] [<7f15a874>] (ath10k_ce_rx_post_buf [ath10k_core]) from
> [<7f2889a4>] (ath10k_pci_diag_read_mem+0x104/0x2a8 [ath10k_pci])
> [   11.458706] [<7f2889a4>] (ath10k_pci_diag_read_mem [ath10k_pci])
> from [<7f288b68>] (ath10k_pci_diag_read32+0x1c/0x2c [ath10k_pci])
> [   11.470767] [<7f288b68>] (ath10k_pci_diag_read32 [ath10k_pci]) from
> [<7f28abe8>] (ath10k_pci_init_config+0x2c/0x290 [ath10k_pci])
> [   11.482314] [<7f28abe8>] (ath10k_pci_init_config [ath10k_pci]) from
> [<7f28d160>] (ath10k_ahb_hif_power_up+0x7c/0xe8 [ath10k_pci])
> [   11.494153] [<7f28d160>] (ath10k_ahb_hif_power_up [ath10k_pci])
> from [<7f135348>] (ath10k_core_register_work+0x84/0x8f8 [ath10k_core])
> [   11.505766] [<7f135348>] (ath10k_core_register_work [ath10k_core])
> from [<8023b614>] (process_one_work+0x1c0/0x2f8)
> [   11.517594] [<8023b614>] (process_one_work) from [<8023c650>]
> (worker_thread+0x280/0x3c0)
> [   11.527919] [<8023c650>] (worker_thread) from [<802408f8>]
> (kthread+0xd8/0xe8)
> [   11.536247] [<802408f8>] (kthread) from [<80209ce8>]
> (ret_from_fork+0x14/0x2c)
> 
> When I revert #1 eventually, my system is back to working.
> So I'm blaming the #1 and #2 could have potential bugs or require
> ath.git branch up-to-date.
> 
> On Mon, Jul 20, 2020 at 5:58 PM Peter Oh <peter.oh at eero.com> wrote:
> >
> > My previous email wasn't sent out.
> >
> > At first I gave these 3 patches.
> > ath10k: Add interrupt summary based CE processing
> >     https://patchwork.kernel.org/patch/11628299/
> > ath10k: Keep track of which interrupts fired, don't poll them
> >     https://patchwork.kernel.org/patch/11654631/
> > ath10k: Get rid of "per_ce_irq" hw param
> >     https://patchwork.kernel.org/patch/11654633/
> > and saw the crash happen and then reverted the top 2 and used the very
> > first one, but it is still happening.
> >
> > On Mon, Jul 20, 2020 at 5:56 PM Peter Oh <peter.oh at eero.com> wrote:
> > >
> > > Since IPQ4019 doesn't support per CE based interrupt summary, I doubt
> > > if this change is correct.
> > > +       ath10k_ce_engine_int_status_clear(ar, ctrl_addr,
> > > +                                         wm_regs->cc_mask | wm_regs->wm_mask);
> > >
> > >
> > > On Mon, Jul 20, 2020 at 5:53 PM Peter Oh <peter.oh at eero.com> wrote:
> > > >
> > > > At first I gave these 3 patches.
> > > > ath10k: Add interrupt summary based CE processing
> > > >     https://patchwork.kernel.org/patch/11628299/
> > > > ath10k: Keep track of which interrupts fired, don't poll them
> > > >     https://patchwork.kernel.org/patch/11654631/
> > > > ath10k: Get rid of "per_ce_irq" hw param
> > > >     https://patchwork.kernel.org/patch/11654633/
> > > > and saw the crash happen and then reverted the top 2 and used the
> very first one, but it is still happening.
> > > >
> > > >
> > > >
> > > > On Mon, Jul 20, 2020 at 5:43 PM Peter Oh <peter.oh at eero.com>
> wrote:
> > > >>
> > > >> I've run 3 units and one of them happens the problem always while
> the
> > > >> other 2 are barely happening.
> > > >>
> > > >> On Mon, Jul 20, 2020 at 5:33 PM Peter Oh <peter.oh at eero.com>
> wrote:
> > > >> >
> > > >> > I'm getting this panic on IPQ4019 system after cherry-picked this
> > > >> > single patch on top of working system.
> > > >> >
> > > >> > [   14.226184] ath10k_ahb a000000.wifi: failed to receive initialized
> > > >> > event from target: 80000000
> > > >> > [   14.326406] !#%&PageFault P<find_dr+0x28/0x64>
> > > >> > L<devres_remove+0x38/0x70> F<005> [00000008]
> > > >> > [   14.326447] Unable to handle kernel NULL pointer dereference at
> > > >> > virtual address 00000008
> > > >> > [   14.333569] pgd = 80cac000
> > > >> > [   14.341892] [00000008] *pgd=00000000
> > > >> > [   14.347804] !#%&Abort P<find_dr+0x28/0x64>
> > > >> > L<devres_remove+0x38/0x70> F<005> FILE<PageFault>
> > > >> > [   14.348067] Internal error: PageFault: 5 [#1] PREEMPT SMP ARM
> > > >> > [   14.356568] Modules linked in: ath10k_pci(+) ecm shortcut_fe_drv
> > > >> > shortcut_fe ath10k_core ath mac80211 cfg80211 compat
> > > >> > [   14.372537] CPU: 3 PID: 301 Comm: systemd-modules Not tainted
> > > >> > 4.4.60-yocto-standard-eero #1
> > > >> > [   14.372805] Hardware name: Qualcomm (Flattened Device Tree)
> > > >> > [   14.380961] task: 9b492300 ti: 9d3f0000 task.ti: 9d3f0000
> > > >> > [   14.386516] PC is at find_dr+0x28/0x64
> > > >> > [   14.392069] LR is at devres_remove+0x38/0x70
> > > >> > [   14.395720] pc : [<804aa498>]    lr : [<804aa564>]    psr: 00010193
> > > >> > [   14.395720] sp : 9d3f7cc8  ip : 00000000  fp : 7f18b380
> > > >> > [   14.400155] r10: 9d995610  r9 : 9b73db64  r8 : 9b740b00
> > > >> > [   14.411343] r7 : 80430990  r6 : 8043097c  r5 : 9b73da10  r4 : 00000000
> > > >> > [   14.416554] r3 : 9b740b00  r2 : 8043097c  r1 : 80430990  r0 : 9b73da10
> > > >> > [   14.423153] Flags: nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM
> > > >> > Segment user
> > > >> > [   14.429663] Control: 10c5387d  Table: 80cac06a  DAC: 00000055
> > > >> > [   14.436865] Process systemd-modules (pid: 301, stack limit =
> 0x9d3f0210)
> > > >> > [   14.442683] Stack: (0x9d3f7cc8 to 0x9d3f8000)
> > > >> > [   14.449455] 7cc0:                   9b73da10 a0010113 80430990
> > > >> > 8043097c 9b740b00 9b73db60
> > > >> > [   14.453716] 7ce0: 9d995610 804aa564 9b740b00 9dbd1f20 9d995600
> > > >> > 9d995600 ffffff92 00000000
> > > >> > [   14.461876] 7d00: 9d995610 804aac4c 9b740b00 80430a94 9dbd5f20
> > > >> > 7f28c584 9dbd5f20 7f28cf28
> > > >> > [   14.470035] 7d20: 7f28f3b2 9dbd1f20 00000001 9cae5960 9d9a16e0
> > > >> > 00000000 00000000 00000000
> > > >> > [   14.478196] 7d40: 8162d420 7f28c9d4 9d995610 7f28fb94 8162d42c
> > > >> > 815a59e0 8162d420 00000003
> > > >> > [   14.486355] 7d60: 9d3f7f54 804a96cc 9d995610 00000000 7f28fb94
> > > >> > 804a7df8 7f28fb94 9d995610
> > > >> > [   14.494516] 7d80: 9d995610 7f28fb94 9d995644 815d8400 00000000
> > > >> > 0000001c 9cae60c8 804a7f9c
> > > >> > [   14.502675] 7da0: 00000000 7f28fb94 804a7f50 804a62c0 9d81fc5c
> > > >> > 9d9f6634 7f28fb94 9b739a00
> > > >> > [   14.510834] 7dc0: 815a5908 804a7344 7f28f3b2 7f28f3b3 7f28fb94
> > > >> > 7f293000 00000000 815b6d48
> > > >> > [   14.518995] 7de0: 815b6d48 804a87a4 9cae61c0 7f293000 00000000
> > > >> > 7f28d2e8 9cae61c0 7f29300c
> > > >> > [   14.527153] 7e00: 9cae61c0 80213468 0018bce1 00000001 8040003f
> > > >> > 802b19d0 9e34ea98 00000000
> > > >> > [   14.535315] 7e20: 9e34eaa8 9e34ea98 8040003e 9e34e8a0
> 9e34e8a0
> > > >> > 9bae8100 9d3f0000 9d801e40
> > > >> > [   14.543474] 7e40: 00004eb1 9e34e8a0 9bae8080 9d3f0000 81621200
> > > >> > 7f28fc00 00000001 81599848
> > > >> > [   14.551632] 7e60: 7f28fc00 00000001 9cae6180 7f28fc48 00000001
> > > >> > 80287704 7f28fc00 9e34e8a0
> > > >> > [   14.559793] 7e80: 7f28fc00 00000001 9cae60c0 80289298 7f28fc0c
> > > >> > 00007fff 7f28fc00 80286a58
> > > >> > [   14.567952] 7ea0: 00000000 815998c4 a13e1138 7f293100 a13dba30
> > > >> > 8088bd0c 7f28fdc4 76cea5cc
> > > >> > [   14.576112] 7ec0: 9d3f7f54 802861d4 00000000 00000000 00000000
> > > >> > 00000000 00000000 00000000
> > > >> > [   14.584269] 7ee0: 6e72656b 00006c65 00000000 00000000 00000000
> > > >> > 00000000 00000000 00000000
> > > >> > [   14.592430] 7f00: 00000000 00000000 00000000 00000000 00000000
> > > >> > 00000000 00000000 81599848
> > > >> > [   14.600590] 7f20: 00000000 00000000 76cea5cc 00000008 0000017b
> > > >> > 80209de4 9d3f0000 00000000
> > > >> > [   14.608751] 7f40: 00000000 80289594 9d3f0000 00000000 7e85fbbc
> > > >> > a13d4000 0000d1b0 a13e0b48
> > > >> > [   14.616911] 7f60: a13e09ac a13dd590 00007e08 00008ca8 00000000
> > > >> > 00000000 00000000 0000313c
> > > >> > [   14.625070] 7f80: 00000026 00000027 0000001d 00000000 00000016
> > > >> > 00000000 00000000 00000000
> > > >> > [   14.633230] 7fa0: 5654ca48 80209c40 00000000 00000000 00000008
> > > >> > 76cea5cc 00000000 00000000
> > > >> > [   14.641390] 7fc0: 00000000 00000000 5654ca48 0000017b 00000000
> > > >> > 00000001 76ea754f 00000000
> > > >> > [   14.649549] 7fe0: 7e85fbc0 7e85fbb0 76ce281c 76c6b830 600f0010
> > > >> > 00000008 00000000 00000000
> > > >> > [   14.657717] [<804aa498>] (find_dr) from [<804aa564>]
> > > >> > (devres_remove+0x38/0x70)
> > > >> > [   14.665868] [<804aa564>] (devres_remove) from [<804aac4c>]
> > > >> > (devres_destroy+0x8/0x24)
> > > >> > [   14.672989] [<804aac4c>] (devres_destroy) from [<80430a94>]
> > > >> > (devm_iounmap+0x18/0x44)
> > > >> > [   14.680927] [<80430a94>] (devm_iounmap) from [<7f28c584>]
> > > >> > (ath10k_ahb_resource_deinit+0x20/0x74 [ath10k_pci])
> > > >> > [   14.688671] [<7f28c584>] (ath10k_ahb_resource_deinit
> [ath10k_pci])
> > > >> > from [<7f28cf28>] (ath10k_ahb_probe+0x554/0x6f4 [ath10k_pci])
> > > >> > [   14.698454] [<7f28cf28>] (ath10k_ahb_probe [ath10k_pci]) from
> > > >> > [<804a96cc>] (platform_drv_probe+0x50/0x9c)
> > > >> > [   14.710061] [<804a96cc>] (platform_drv_probe) from [<804a7df8>]
> > > >> > (driver_probe_device+0x2ac/0x404)
> > > >> > [   14.719520] [<804a7df8>] (driver_probe_device) from
> [<804a7f9c>]
> > > >> > (__driver_attach+0x4c/0x8c)
> > > >> > [   14.728374] [<804a7f9c>] (__driver_attach) from [<804a62c0>]
> > > >> > (bus_for_each_dev+0x7c/0x8c)
> > > >> > [   14.736880] [<804a62c0>] (bus_for_each_dev) from [<804a7344>]
> > > >> > (bus_add_driver+0x1b4/0x234)
> > > >> > [   14.744952] [<804a7344>] (bus_add_driver) from [<804a87a4>]
> > > >> > (driver_register+0xa0/0xe0)
> > > >> > [   14.753136] [<804a87a4>] (driver_register) from [<7f28d2e8>]
> > > >> > (ath10k_ahb_init+0x10/0x38 [ath10k_pci])
> > > >> > [   14.761061] [<7f28d2e8>] (ath10k_ahb_init [ath10k_pci]) from
> > > >> > [<7f29300c>] (__init_backport+0xc/0x100 [ath10k_pci])
> > > >> > [   14.770418] [<7f29300c>] (__init_backport [ath10k_pci]) from
> > > >> > [<80213468>] (do_one_initcall+0x1c4/0x20c)
> > > >> > [   14.780633] [<80213468>] (do_one_initcall) from [<80287704>]
> > > >> > (do_init_module+0x54/0x1ac)
> > > >> > [   14.789916] [<80287704>] (do_init_module) from [<80289298>]
> > > >> > (load_module+0x19e0/0x1b04)
> > > >> > [   14.798249] [<80289298>] (load_module) from [<80289594>]
> > > >> > (SyS_finit_module+0x8c/0x9c)
> > > >> > [   14.805975] [<80289594>] (SyS_finit_module) from [<80209c40>]
> > > >> > (ret_fast_syscall+0x0/0x34)
> > > >> > [   14.813959] Code: e1a08003 e1540009 03a04000 0a00000c
> (e5943008)
> > > >> > [   14.822108] ---[ end trace f4da008c1c165fb3 ]---
> > > >> > [   14.830623] Kernel panic - not syncing: Fatal exception
> > > >> > [   14.832876] CPU1: stopping
> > > >> > [   14.837820] CPU: 1 PID: 343 Comm: rngd Tainted: G      D
> > > >> > 4.4.60-yocto-standard-eero #1
> > > >> > [   14.840601] Hardware name: Qualcomm (Flattened Device Tree)
> > > >> > [   14.849210] [<8021ed7c>] (unwind_backtrace) from [<8021b730>]
> > > >> > (show_stack+0x10/0x14)
> > > >> > [   14.854672] [<8021b730>] (show_stack) from [<8041b8dc>]
> > > >> > (dump_stack+0x7c/0x98)
> > > >> > [   14.862658] [<8041b8dc>] (dump_stack) from [<8021dfc8>]
> > > >> > (handle_IPI+0xdc/0x164)
> > > >> > [   14.869688] [<8021dfc8>] (handle_IPI) from [<802093e8>]
> > > >> > (gic_handle_irq+0x80/0x8c)
> > > >> > [   14.876893] [<802093e8>] (gic_handle_irq) from [<8020a844>]
> > > >> > (__irq_usr+0x44/0x60)
> > > >> > [   14.884524] Exception stack(0x9beaffb0 to 0x9beafff8)
> > > >> > [   14.892076] ffa0:                                     0c27987c
> > > >> > 40016b9f 0c27987d 0000001f
> > > >> > [   14.897118] ffc0: 00000001 763fedbc 565a344c 54b3de80 54b3e50c
> > > >> > 00000001 7e817c00 763fed0c
> > > >> > [   14.905277] ffe0: fffffffe 763fecc0 00000018 76ec3e18 30010010
> ffffffff
> > > >> > [   14.913430] CPU2: stopping
> > > >> > [   14.919849] CPU: 2 PID: 344 Comm: rngd Tainted: G      D
> > > >> > 4.4.60-yocto-standard-eero #1
> > > >> > [   14.922631] Hardware name: Qualcomm (Flattened Device Tree)
> > > >> > [   14.931236] [<8021ed7c>] (unwind_backtrace) from [<8021b730>]
> > > >> > (show_stack+0x10/0x14)
> > > >> > [   14.936703] [<8021b730>] (show_stack) from [<8041b8dc>]
> > > >> > (dump_stack+0x7c/0x98)
> > > >> > [   14.944688] [<8041b8dc>] (dump_stack) from [<8021dfc8>]
> > > >> > (handle_IPI+0xdc/0x164)
> > > >> > [   14.951719] [<8021dfc8>] (handle_IPI) from [<802093e8>]
> > > >> > (gic_handle_irq+0x80/0x8c)
> > > >> > [   14.958924] [<802093e8>] (gic_handle_irq) from [<8020a844>]
> > > >> > (__irq_usr+0x44/0x60)
> > > >> > [   14.966554] Exception stack(0x9beb7fb0 to 0x9beb7ff8)
> > > >> > [   14.974107] 7fa0:                                     fffffff7
> > > >> > 00000017 a6000000 0000014a
> > > >> > [   14.979150] 7fc0: 00000002 759fedbc 565a3470 54b3de80 54b3e50c
> > > >> > 00000001 7e817c00 759fed0c
> > > >> > [   14.987307] 7fe0: 00000009 759fecc0 00000018 76ec3cdc 80010010
> ffffffff
> > > >> > [   14.995461] CPU0: stopping
> > > >> > [   15.001882] CPU: 0 PID: 341 Comm: rngd Tainted: G      D
> > > >> > 4.4.60-yocto-standard-eero #1
> > > >> > [   15.004663] Hardware name: Qualcomm (Flattened Device Tree)
> > > >> > [   15.013267] [<8021ed7c>] (unwind_backtrace) from [<8021b730>]
> > > >> > (show_stack+0x10/0x14)
> > > >> > [   15.018734] [<8021b730>] (show_stack) from [<8041b8dc>]
> > > >> > (dump_stack+0x7c/0x98)
> > > >> > [   15.026719] [<8041b8dc>] (dump_stack) from [<8021dfc8>]
> > > >> > (handle_IPI+0xdc/0x164)
> > > >> > [   15.033752] [<8021dfc8>] (handle_IPI) from [<802093e8>]
> > > >> > (gic_handle_irq+0x80/0x8c)
> > > >> > [   15.040955] [<802093e8>] (gic_handle_irq) from [<8020a844>]
> > > >> > (__irq_usr+0x44/0x60)
> > > >> > [   15.048585] Exception stack(0x9be87fb0 to 0x9be87ff8)
> > > >> > [   15.056139] 7fa0:                                     00000000
> > > >> > 00000000 a7e3391d 6a11d866
> > > >> > [   15.061181] 7fc0: 00000000 76d15dbc 565a3428 54b3de80 54b3e50c
> > > >> > 00000001 7e817c00 76d15d0c
> > > >> > [   15.069339] 7fe0: ffffffeb 76d15cc0 00000018 76ec3d60 80010010
> ffffffff
> > > >> > [   15.091080] Rebooting in 5 seconds..
> > > >> >
> > > >> >
> > > >> > On Wed, Jul 15, 2020 at 11:39 PM Kalle Valo
> <kvalo at codeaurora.org> wrote:
> > > >> > >
> > > >> > > Brian Norris <briannorris at chromium.org> writes:
> > > >> > >
> > > >> > > > On Fri, Jun 26, 2020 at 2:49 PM Doug Anderson
> <dianders at chromium.org> wrote:
> > > >> > > >> I should also note that, while I'm not terribly familiar with Kalle's
> > > >> > > >> workflow, I would have expected to see him in the "To:" list.
> I've
> > > >> > > >> added him, but it's possible he'll need you to repost the patch
> with
> > > >> > > >> him in the "To:" list.
> > > >> > > >
> > > >> > > >
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingp
> atches#who_to_address
> > > >> > > >
> https://wireless.wiki.kernel.org/en/users/drivers/ath10k/submittingpatches
> > > >> > > >
> > > >> > > > Patchwork is his patch queue, so I don't think you need to
> address him directly.
> > > >> > >
> > > >> > > Yup, I take all patches from patchwork so no need to Cc me.
> > > >> > >
> > > >> > > --
> > > >> > >
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingp
> atches



From dianders at chromium.org  Tue Jul 21 11:37:19 2020
From: dianders at chromium.org (Doug Anderson)
Date: Tue, 21 Jul 2020 08:37:19 -0700
Subject: [PATCH] ath10k: Add interrupt summary based CE processing
In-Reply-To: <CALhWmc11OefTh6Ov5GqP-yHMVTUO4r9CxqkdHT1F3yzor72v7g@mail.gmail.com>
References: <1593193967-29897-1-git-send-email-pillair@codeaurora.org>
 <CAD=FV=V_ynwukeR92nbJXkuQ7OAW4mLaTjxko7fXt5aEfDUNhA@mail.gmail.com>
 <CAD=FV=XJDmGbEJQ1U-VDuN2p0+V+uRm_1=DwBnDPmPQsXqS4ZA@mail.gmail.com>
 <CA+ASDXNOCFZhdNMDk9XTuC2H+owQ0+wHipDbkJAGnU9q7BXz_w@mail.gmail.com>
 <871rlcx8uv.fsf@codeaurora.org>
 <CALhWmc1PbTKhrkaPn9yfpx3gZHAMuR-bPY=4_o4wQHv_H5D9dA@mail.gmail.com>
 <CALhWmc3i9Z+KiG1cJNvpSWNsiFhOa5jBw=XfcFz_gKwi_5QibA@mail.gmail.com>
 <CALhWmc1B0+SONV6_AF+nUzgxZdekPD3sZuhrsmwVQx1Q-cgT_g@mail.gmail.com>
 <CALhWmc0qF5stKRcikjwbeFmE-32hNCDazgQdqTMidUyt7u-T1Q@mail.gmail.com>
 <CALhWmc0JtQZE5CfLPb1WnwhE9wCYsjE-53kYWbwtFCs1k7FrCQ@mail.gmail.com>
 <CALhWmc11OefTh6Ov5GqP-yHMVTUO4r9CxqkdHT1F3yzor72v7g@mail.gmail.com>
Message-ID: <CAD=FV=UdeQTxbgitY3cQc+s8Pc7Lna7TWpAfzJdfXz-whjX1Qg@mail.gmail.com>

Hi,

On Mon, Jul 20, 2020 at 6:32 PM Peter Oh <peter.oh at eero.com> wrote:
>
> I'll take my word back.
> It's not this patch problem, but by others.
> I have 2 extra patches before the 3 patches so my system looks like
>
> backports from ath.git 5.6-rc1 + linux kernel 4.4 (similar to OpenWrt)
> On top of the working system, I cherry-picked these 5.
>
> #1.
> ath10k: Avoid override CE5 configuration for QCA99X0 chipsets
> ath.git commit 521fc37be3d879561ca5ab42d64719cf94116af0
> #2.
> ath10k: Fix NULL pointer dereference in AHB device probe
> wireless-drivers.git commit 1cfd3426ef989b83fa6176490a38777057e57f6c
> #3.
> ath10k: Add interrupt summary based CE processing
> https://patchwork.kernel.org/patch/11628299/
> #4.
> ath10k: Keep track of which interrupts fired, don't poll them
> https://patchwork.kernel.org/patch/11654631/
> #5.
> ath10k: Get rid of "per_ce_irq" hw param
> https://patchwork.kernel.org/patch/11654633/
>
> The error "[  14.226184] ath10k_ahb a000000.wifi: failed to receive
> initialized event from target: 80000000" is because of #1 and #2,
> since this happens even after I reverted #3~#5.
> Once I reverted all except #1 I got another crash.
>
> [   11.179595] !#%&PageFault P<__ath10k_ce_rx_post_buf+0x14/0x98
> [ath10k_core]> L<0x4bc00> F<005> [0000000c]
> [   11.179643] Unable to handle kernel NULL pointer dereference at
> virtual address 0000000c
> [   11.439207] [<7f15a69c>] (__ath10k_ce_rx_post_buf [ath10k_core])
> from [<7f15a874>] (ath10k_ce_rx_post_buf+0x3c/0x50 [ath10k_core])
> [   11.447204] [<7f15a874>] (ath10k_ce_rx_post_buf [ath10k_core]) from
> [<7f2889a4>] (ath10k_pci_diag_read_mem+0x104/0x2a8 [ath10k_pci])
> [   11.458706] [<7f2889a4>] (ath10k_pci_diag_read_mem [ath10k_pci])
> from [<7f288b68>] (ath10k_pci_diag_read32+0x1c/0x2c [ath10k_pci])
> [   11.470767] [<7f288b68>] (ath10k_pci_diag_read32 [ath10k_pci]) from
> [<7f28abe8>] (ath10k_pci_init_config+0x2c/0x290 [ath10k_pci])
> [   11.482314] [<7f28abe8>] (ath10k_pci_init_config [ath10k_pci]) from
> [<7f28d160>] (ath10k_ahb_hif_power_up+0x7c/0xe8 [ath10k_pci])
> [   11.494153] [<7f28d160>] (ath10k_ahb_hif_power_up [ath10k_pci])
> from [<7f135348>] (ath10k_core_register_work+0x84/0x8f8 [ath10k_core])
> [   11.505766] [<7f135348>] (ath10k_core_register_work [ath10k_core])
> from [<8023b614>] (process_one_work+0x1c0/0x2f8)
> [   11.517594] [<8023b614>] (process_one_work) from [<8023c650>]
> (worker_thread+0x280/0x3c0)
> [   11.527919] [<8023c650>] (worker_thread) from [<802408f8>]
> (kthread+0xd8/0xe8)
> [   11.536247] [<802408f8>] (kthread) from [<80209ce8>]
> (ret_from_fork+0x14/0x2c)
>
> When I revert #1 eventually, my system is back to working.
> So I'm blaming the #1 and #2 could have potential bugs or require
> ath.git branch up-to-date.

You caught me just as I was signing off yesterday evening, but just to
confirm that you are now fairly certain that none of the 3 patches I
was involved with[*] are related to your problems.  If that's wrong
and there's an action I need to take on the patches then let me know!
:-)

[*] The three patches I was involved with:

ath10k: Add interrupt summary based CE processing
https://patchwork.kernel.org/patch/11628299/

ath10k: Keep track of which interrupts fired, don't poll them
https://patchwork.kernel.org/patch/11654631/

ath10k: Get rid of "per_ce_irq" hw param
https://patchwork.kernel.org/patch/11654633/

-Doug


From pillair at codeaurora.org  Tue Jul 21 13:14:21 2020
From: pillair at codeaurora.org (Rakesh Pillai)
Date: Tue, 21 Jul 2020 22:44:21 +0530
Subject: [RFC 2/7] ath10k: Add support to process rx packet in thread
In-Reply-To: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
References: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
Message-ID: <1595351666-28193-3-git-send-email-pillair@codeaurora.org>

NAPI instance gets scheduled on a CPU core on which
the IRQ was triggered. The processing of rx packets
can be CPU intensive and since NAPI cannot be moved
to a different CPU core, to get better performance,
its better to move the gist of rx packet processing
in a high priority thread.

Add the init/deinit part for a thread to process the
receive packets.

Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.1-01040-QCAHLSWMTPLZ-1

Signed-off-by: Rakesh Pillai <pillair at codeaurora.org>
---
 drivers/net/wireless/ath/ath10k/core.c | 33 +++++++++++++++++++++++++++
 drivers/net/wireless/ath/ath10k/core.h | 23 +++++++++++++++++++
 drivers/net/wireless/ath/ath10k/snoc.c | 41 ++++++++++++++++++++++++++++++++++
 3 files changed, 97 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 9104496..2b520a0 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -668,6 +668,39 @@ static unsigned int ath10k_core_get_fw_feature_str(char *buf,
 	return scnprintf(buf, buf_len, "%s", ath10k_core_fw_feature_str[feat]);
 }
 
+int ath10k_core_thread_shutdown(struct ath10k *ar,
+				struct ath10k_thread *thread)
+{
+	ath10k_dbg(ar, ATH10K_DBG_BOOT, "shutting down %s\n", thread->name);
+	set_bit(ATH10K_THREAD_EVENT_SHUTDOWN, thread->event_flags);
+	wake_up_process(thread->task);
+	wait_for_completion(&thread->shutdown);
+	ath10k_info(ar, "thread %s exited\n", thread->name);
+
+	return 0;
+}
+EXPORT_SYMBOL(ath10k_core_thread_shutdown);
+
+int ath10k_core_thread_init(struct ath10k *ar,
+			    struct ath10k_thread *thread,
+			    int (*handler)(void *data),
+			    char *thread_name)
+{
+	thread->task = kthread_create(handler, thread, thread_name);
+	if (IS_ERR(thread->task))
+		return -EINVAL;
+
+	init_waitqueue_head(&thread->wait_q);
+	init_completion(&thread->shutdown);
+	memcpy(thread->name, thread_name, ATH10K_THREAD_NAME_SIZE_MAX);
+	clear_bit(ATH10K_THREAD_EVENT_SHUTDOWN, thread->event_flags);
+	ath10k_info(ar, "Starting thread %s\n", thread_name);
+	wake_up_process(thread->task);
+
+	return 0;
+}
+EXPORT_SYMBOL(ath10k_core_thread_init);
+
 void ath10k_core_get_fw_features_str(struct ath10k *ar,
 				     char *buf,
 				     size_t buf_len)
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 5c18f6c..96919e8 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -970,6 +970,22 @@ struct ath10k_bus_params {
 	bool hl_msdu_ids;
 };
 
+#define ATH10K_THREAD_NAME_SIZE_MAX	32
+
+enum ath10k_thread_events {
+	ATH10K_THREAD_EVENT_SHUTDOWN,
+	ATH10K_THREAD_EVENT_MAX,
+};
+
+struct ath10k_thread {
+	struct ath10k *ar;
+	struct task_struct *task;
+	struct completion shutdown;
+	wait_queue_head_t wait_q;
+	DECLARE_BITMAP(event_flags, ATH10K_THREAD_EVENT_MAX);
+	char name[ATH10K_THREAD_NAME_SIZE_MAX];
+};
+
 struct ath10k {
 	struct ath_common ath_common;
 	struct ieee80211_hw *hw;
@@ -982,6 +998,7 @@ struct ath10k {
 	} msa;
 	u8 mac_addr[ETH_ALEN];
 
+	struct ath10k_thread rx_thread;
 	enum ath10k_hw_rev hw_rev;
 	u16 dev_id;
 	u32 chip_id;
@@ -1276,6 +1293,12 @@ static inline bool ath10k_peer_stats_enabled(struct ath10k *ar)
 
 extern unsigned long ath10k_coredump_mask;
 
+int ath10k_core_thread_shutdown(struct ath10k *ar,
+				struct ath10k_thread *thread);
+int ath10k_core_thread_init(struct ath10k *ar,
+			    struct ath10k_thread *thread,
+			    int (*handler)(void *data),
+			    char *thread_name);
 struct ath10k *ath10k_core_create(size_t priv_size, struct device *dev,
 				  enum ath10k_bus bus,
 				  enum ath10k_hw_rev hw_rev,
diff --git a/drivers/net/wireless/ath/ath10k/snoc.c b/drivers/net/wireless/ath/ath10k/snoc.c
index 1ef5fdb..463c34e 100644
--- a/drivers/net/wireless/ath/ath10k/snoc.c
+++ b/drivers/net/wireless/ath/ath10k/snoc.c
@@ -909,6 +909,31 @@ static void ath10k_snoc_buffer_cleanup(struct ath10k *ar)
 	}
 }
 
+int ath10k_snoc_rx_thread_loop(void *data)
+{
+	struct ath10k_thread *rx_thread = data;
+	struct ath10k *ar = rx_thread->ar;
+	bool shutdown = false;
+
+	ath10k_dbg(ar, ATH10K_DBG_SNOC, "rx thread started\n");
+	set_user_nice(current, -1);
+
+	while (!shutdown) {
+		wait_event_interruptible(
+			rx_thread->wait_q,
+			(test_bit(ATH10K_THREAD_EVENT_SHUTDOWN,
+				  rx_thread->event_flags)));
+		if (test_and_clear_bit(ATH10K_THREAD_EVENT_SHUTDOWN,
+				       rx_thread->event_flags))
+			shutdown = true;
+	}
+
+	ath10k_dbg(ar, ATH10K_DBG_SNOC, "rx thread exiting\n");
+	complete(&rx_thread->shutdown);
+
+	do_exit(0);
+}
+
 static void ath10k_snoc_hif_stop(struct ath10k *ar)
 {
 	if (!test_bit(ATH10K_FLAG_CRASH_FLUSH, &ar->dev_flags))
@@ -916,6 +941,7 @@ static void ath10k_snoc_hif_stop(struct ath10k *ar)
 
 	napi_synchronize(&ar->napi);
 	napi_disable(&ar->napi);
+	ath10k_core_thread_shutdown(ar, &ar->rx_thread);
 	ath10k_snoc_buffer_cleanup(ar);
 	ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot hif stop\n");
 }
@@ -923,9 +949,19 @@ static void ath10k_snoc_hif_stop(struct ath10k *ar)
 static int ath10k_snoc_hif_start(struct ath10k *ar)
 {
 	struct ath10k_snoc *ar_snoc = ath10k_snoc_priv(ar);
+	int ret;
 
 	bitmap_clear(ar_snoc->pending_ce_irqs, 0, CE_COUNT_MAX);
 	napi_enable(&ar->napi);
+
+	ret = ath10k_core_thread_init(ar, &ar->rx_thread,
+				      ath10k_snoc_rx_thread_loop,
+				      "ath10k_rx_thread");
+	if (ret) {
+		ath10k_err(ar, "failed to start rx thread\n");
+		goto rx_thread_fail;
+	}
+
 	ath10k_snoc_irq_enable(ar);
 	ath10k_snoc_rx_post(ar);
 
@@ -934,6 +970,10 @@ static int ath10k_snoc_hif_start(struct ath10k *ar)
 	ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot hif start\n");
 
 	return 0;
+
+rx_thread_fail:
+	napi_disable(&ar->napi);
+	return ret;
 }
 
 static int ath10k_snoc_init_pipes(struct ath10k *ar)
@@ -1652,6 +1692,7 @@ static int ath10k_snoc_probe(struct platform_device *pdev)
 		return -ENOMEM;
 	}
 
+	ar->rx_thread.ar = ar;
 	ar_snoc = ath10k_snoc_priv(ar);
 	ar_snoc->dev = pdev;
 	platform_set_drvdata(pdev, ar);
-- 
2.7.4



From pillair at codeaurora.org  Tue Jul 21 13:14:19 2020
From: pillair at codeaurora.org (Rakesh Pillai)
Date: Tue, 21 Jul 2020 22:44:19 +0530
Subject: [RFC 0/7] Add support to process rx packets in thread
Message-ID: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>

NAPI gets scheduled on the CPU core which got the
interrupt. The linux scheduler cannot move it to a
different core, even if the CPU on which NAPI is running
is heavily loaded. This can lead to degraded wifi
performance when running traffic at peak data rates.

A thread on the other hand can be moved to different
CPU cores, if the one on which its running is heavily
loaded. During high incoming data traffic, this gives
better performance, since the thread can be moved to a
less loaded or sometimes even a more powerful CPU core
to account for the required CPU performance in order
to process the incoming packets.

This patch series adds the support to use a high priority
thread to process the incoming packets, as opposed to
everything being done in NAPI context.

The rx thread can be enabled by using a module parameter
when loading the ath10k_snoc module.

---
This patch series is dependent on the below patch series
https://patchwork.kernel.org/project/ath10k/list/?series=315759

Rakesh Pillai (7):
  mac80211: Add check for napi handle before WARN_ON
  ath10k: Add support to process rx packet in thread
  ath10k: Add module param to enable rx thread
  ath10k: Do not exhaust budget on process tx completion
  ath10k: Handle the rx packet processing in thread
  ath10k: Add deliver to stack from thread context
  ath10k: Handle rx thread suspend and resume

 drivers/net/wireless/ath/ath10k/core.c   |  64 +++++++++++++++++++
 drivers/net/wireless/ath/ath10k/core.h   |  33 ++++++++++
 drivers/net/wireless/ath/ath10k/htt.h    |   2 +
 drivers/net/wireless/ath/ath10k/htt_rx.c |  66 ++++++++++++++-----
 drivers/net/wireless/ath/ath10k/snoc.c   | 105 ++++++++++++++++++++++++++++++-
 net/mac80211/rx.c                        |   2 +-
 6 files changed, 253 insertions(+), 19 deletions(-)

-- 
2.7.4



From pillair at codeaurora.org  Tue Jul 21 13:14:23 2020
From: pillair at codeaurora.org (Rakesh Pillai)
Date: Tue, 21 Jul 2020 22:44:23 +0530
Subject: [RFC 4/7] ath10k: Do not exhaust budget on process tx completion
In-Reply-To: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
References: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
Message-ID: <1595351666-28193-5-git-send-email-pillair@codeaurora.org>

Currently the entire NAPI budget is marked as exhausted
if any tx completion is processed.
In scenarios of bi-directional traffic, this leads to a
situation where the irqs are never enabled and the NAPI
is rescheuled again and again.

Increase the work done quota by the number of tx completions
which are processed in the NAPI context.

Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.1-01040-QCAHLSWMTPLZ-1

Signed-off-by: Rakesh Pillai <pillair at codeaurora.org>
---
 drivers/net/wireless/ath/ath10k/htt_rx.c | 15 ++++++---------
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index cac05e7..a4a6618 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -4077,21 +4077,18 @@ int ath10k_htt_txrx_compl_task(struct ath10k *ar, int budget)
 	/* Deliver received data after processing data from hardware */
 	quota = ath10k_htt_rx_deliver_msdu(ar, quota, budget);
 
-	/* 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:
 	 *  Note that with only one concurrent reader and one concurrent writer,
 	 *  you don't need extra locking to use these macro.
 	 */
-	while (kfifo_get(&htt->txdone_fifo, &tx_done))
+	while (kfifo_get(&htt->txdone_fifo, &tx_done)) {
 		ath10k_txrx_tx_unref(htt, &tx_done);
+		quota++;
+	}
+
+	if (quota > budget)
+		resched_napi = true;
 
 	ath10k_mac_tx_push_pending(ar);
 
-- 
2.7.4



From pillair at codeaurora.org  Tue Jul 21 13:14:22 2020
From: pillair at codeaurora.org (Rakesh Pillai)
Date: Tue, 21 Jul 2020 22:44:22 +0530
Subject: [RFC 3/7] ath10k: Add module param to enable rx thread
In-Reply-To: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
References: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
Message-ID: <1595351666-28193-4-git-send-email-pillair@codeaurora.org>

Add a module parameter to enable or disable
the processing of received packets in rx thread.

To enable rx packet processing in a thread
context, use the belo command to load driver:
insmod ath10k_snoc.ko rx_thread_enable=1

Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.1-01040-QCAHLSWMTPLZ-1

Signed-off-by: Rakesh Pillai <pillair at codeaurora.org>
---
 drivers/net/wireless/ath/ath10k/core.h |  1 +
 drivers/net/wireless/ath/ath10k/snoc.c | 24 +++++++++++++++++-------
 2 files changed, 18 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 96919e8..59bdf11 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -998,6 +998,7 @@ struct ath10k {
 	} msa;
 	u8 mac_addr[ETH_ALEN];
 
+	bool rx_thread_enable;
 	struct ath10k_thread rx_thread;
 	enum ath10k_hw_rev hw_rev;
 	u16 dev_id;
diff --git a/drivers/net/wireless/ath/ath10k/snoc.c b/drivers/net/wireless/ath/ath10k/snoc.c
index 463c34e..f01725b 100644
--- a/drivers/net/wireless/ath/ath10k/snoc.c
+++ b/drivers/net/wireless/ath/ath10k/snoc.c
@@ -26,6 +26,12 @@
 #define CE_POLL_PIPE 4
 #define ATH10K_SNOC_WAKE_IRQ 2
 
+static bool ath10k_rx_thread_enable;
+
+module_param_named(rx_thread_enable, ath10k_rx_thread_enable, bool, 0644);
+
+MODULE_PARM_DESC(rx_thread_enable, "Receive packet processing in thread");
+
 static char *const ce_name[] = {
 	"WLAN_CE_0",
 	"WLAN_CE_1",
@@ -941,7 +947,8 @@ static void ath10k_snoc_hif_stop(struct ath10k *ar)
 
 	napi_synchronize(&ar->napi);
 	napi_disable(&ar->napi);
-	ath10k_core_thread_shutdown(ar, &ar->rx_thread);
+	if (ar->rx_thread_enable)
+		ath10k_core_thread_shutdown(ar, &ar->rx_thread);
 	ath10k_snoc_buffer_cleanup(ar);
 	ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot hif stop\n");
 }
@@ -954,12 +961,14 @@ static int ath10k_snoc_hif_start(struct ath10k *ar)
 	bitmap_clear(ar_snoc->pending_ce_irqs, 0, CE_COUNT_MAX);
 	napi_enable(&ar->napi);
 
-	ret = ath10k_core_thread_init(ar, &ar->rx_thread,
-				      ath10k_snoc_rx_thread_loop,
-				      "ath10k_rx_thread");
-	if (ret) {
-		ath10k_err(ar, "failed to start rx thread\n");
-		goto rx_thread_fail;
+	if (ar->rx_thread_enable) {
+		ret = ath10k_core_thread_init(ar, &ar->rx_thread,
+					      ath10k_snoc_rx_thread_loop,
+					      "ath10k_rx_thread");
+		if (ret) {
+			ath10k_err(ar, "failed to start rx thread\n");
+			goto rx_thread_fail;
+		}
 	}
 
 	ath10k_snoc_irq_enable(ar);
@@ -1693,6 +1702,7 @@ static int ath10k_snoc_probe(struct platform_device *pdev)
 	}
 
 	ar->rx_thread.ar = ar;
+	ar->rx_thread_enable = ath10k_rx_thread_enable;
 	ar_snoc = ath10k_snoc_priv(ar);
 	ar_snoc->dev = pdev;
 	platform_set_drvdata(pdev, ar);
-- 
2.7.4



From pillair at codeaurora.org  Tue Jul 21 13:14:26 2020
From: pillair at codeaurora.org (Rakesh Pillai)
Date: Tue, 21 Jul 2020 22:44:26 +0530
Subject: [RFC 7/7] ath10k: Handle rx thread suspend and resume
In-Reply-To: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
References: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
Message-ID: <1595351666-28193-8-git-send-email-pillair@codeaurora.org>

During the system suspend or resume, the rx thread
also needs to be suspended or resume respectively.

Handle the rx thread as well during the system
suspend and resume.

Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.1-01040-QCAHLSWMTPLZ-1

Signed-off-by: Rakesh Pillai <pillair at codeaurora.org>
---
 drivers/net/wireless/ath/ath10k/core.c | 23 ++++++++++++++++++
 drivers/net/wireless/ath/ath10k/core.h |  5 ++++
 drivers/net/wireless/ath/ath10k/snoc.c | 44 +++++++++++++++++++++++++++++++++-
 3 files changed, 71 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 4064fa2..b82b355 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -668,6 +668,27 @@ static unsigned int ath10k_core_get_fw_feature_str(char *buf,
 	return scnprintf(buf, buf_len, "%s", ath10k_core_fw_feature_str[feat]);
 }
 
+int ath10k_core_thread_suspend(struct ath10k_thread *thread)
+{
+	ath10k_dbg(thread->ar, ATH10K_DBG_BOOT, "Suspending thread %s\n",
+		   thread->name);
+	set_bit(ATH10K_THREAD_EVENT_SUSPEND, thread->event_flags);
+	wait_for_completion(&thread->suspend);
+
+	return 0;
+}
+EXPORT_SYMBOL(ath10k_core_thread_suspend);
+
+int ath10k_core_thread_resume(struct ath10k_thread *thread)
+{
+	ath10k_dbg(thread->ar, ATH10K_DBG_BOOT, "Resuming thread %s\n",
+		   thread->name);
+	complete(&thread->resume);
+
+	return 0;
+}
+EXPORT_SYMBOL(ath10k_core_thread_resume);
+
 void ath10k_core_thread_post_event(struct ath10k_thread *thread,
 				   enum ath10k_thread_events event)
 {
@@ -700,6 +721,8 @@ int ath10k_core_thread_init(struct ath10k *ar,
 
 	init_waitqueue_head(&thread->wait_q);
 	init_completion(&thread->shutdown);
+	init_completion(&thread->suspend);
+	init_completion(&thread->resume);
 	memcpy(thread->name, thread_name, ATH10K_THREAD_NAME_SIZE_MAX);
 	clear_bit(ATH10K_THREAD_EVENT_SHUTDOWN, thread->event_flags);
 	ath10k_info(ar, "Starting thread %s\n", thread_name);
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 596d31b..df65e75 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -976,6 +976,7 @@ enum ath10k_thread_events {
 	ATH10K_THREAD_EVENT_SHUTDOWN,
 	ATH10K_THREAD_EVENT_RX_POST,
 	ATH10K_THREAD_EVENT_TX_POST,
+	ATH10K_THREAD_EVENT_SUSPEND,
 	ATH10K_THREAD_EVENT_MAX,
 };
 
@@ -983,6 +984,8 @@ struct ath10k_thread {
 	struct ath10k *ar;
 	struct task_struct *task;
 	struct completion shutdown;
+	struct completion suspend;
+	struct completion resume;
 	wait_queue_head_t wait_q;
 	DECLARE_BITMAP(event_flags, ATH10K_THREAD_EVENT_MAX);
 	char name[ATH10K_THREAD_NAME_SIZE_MAX];
@@ -1296,6 +1299,8 @@ static inline bool ath10k_peer_stats_enabled(struct ath10k *ar)
 
 extern unsigned long ath10k_coredump_mask;
 
+int ath10k_core_thread_suspend(struct ath10k_thread *thread);
+int ath10k_core_thread_resume(struct ath10k_thread *thread);
 void ath10k_core_thread_post_event(struct ath10k_thread *thread,
 				   enum ath10k_thread_events event);
 int ath10k_core_thread_shutdown(struct ath10k *ar,
diff --git a/drivers/net/wireless/ath/ath10k/snoc.c b/drivers/net/wireless/ath/ath10k/snoc.c
index 3eb5eac..a373b2b 100644
--- a/drivers/net/wireless/ath/ath10k/snoc.c
+++ b/drivers/net/wireless/ath/ath10k/snoc.c
@@ -932,13 +932,31 @@ int ath10k_snoc_rx_thread_loop(void *data)
 					    rx_thread->event_flags) ||
 			 test_and_clear_bit(ATH10K_THREAD_EVENT_TX_POST,
 					    rx_thread->event_flags) ||
+			 test_bit(ATH10K_THREAD_EVENT_SUSPEND,
+				  rx_thread->event_flags) ||
 			 test_bit(ATH10K_THREAD_EVENT_SHUTDOWN,
 				  rx_thread->event_flags)));
 
+		if (test_and_clear_bit(ATH10K_THREAD_EVENT_SUSPEND,
+				       rx_thread->event_flags)) {
+			complete(&rx_thread->suspend);
+			ath10k_info(ar, "rx thread suspend\n");
+			wait_for_completion(&rx_thread->resume);
+			ath10k_info(ar, "rx thread resume\n");
+		}
+
 		ath10k_htt_txrx_compl_task(ar, thread_budget);
 		if (test_and_clear_bit(ATH10K_THREAD_EVENT_SHUTDOWN,
 				       rx_thread->event_flags))
 			shutdown = true;
+
+		if (test_and_clear_bit(ATH10K_THREAD_EVENT_SUSPEND,
+				       rx_thread->event_flags)) {
+			complete(&rx_thread->suspend);
+			ath10k_info(ar, "rx thread suspend\n");
+			wait_for_completion(&rx_thread->resume);
+			ath10k_info(ar, "rx thread resume\n");
+		}
 	}
 
 	ath10k_dbg(ar, ATH10K_DBG_SNOC, "rx thread exiting\n");
@@ -1133,15 +1151,30 @@ static int ath10k_snoc_hif_suspend(struct ath10k *ar)
 	if (!device_may_wakeup(ar->dev))
 		return -EPERM;
 
+	if (ar->rx_thread_enable) {
+		ret = ath10k_core_thread_suspend(&ar->rx_thread);
+		if (ret) {
+			ath10k_err(ar, "failed to suspend rx_thread, %d\n",
+				   ret);
+			return ret;
+		}
+	}
+
 	ret = enable_irq_wake(ar_snoc->ce_irqs[ATH10K_SNOC_WAKE_IRQ].irq_line);
 	if (ret) {
 		ath10k_err(ar, "failed to enable wakeup irq :%d\n", ret);
-		return ret;
+		goto fail;
 	}
 
 	ath10k_dbg(ar, ATH10K_DBG_SNOC, "snoc device suspended\n");
 
 	return ret;
+
+fail:
+	if (ar->rx_thread_enable)
+		ath10k_core_thread_resume(&ar->rx_thread);
+
+	return ret;
 }
 
 static int ath10k_snoc_hif_resume(struct ath10k *ar)
@@ -1158,6 +1191,15 @@ static int ath10k_snoc_hif_resume(struct ath10k *ar)
 		return ret;
 	}
 
+	if (ar->rx_thread_enable) {
+		ret = ath10k_core_thread_resume(&ar->rx_thread);
+		if (ret) {
+			ath10k_err(ar, "failed to suspend rx_thread, %d\n",
+				   ret);
+			return ret;
+		}
+	}
+
 	ath10k_dbg(ar, ATH10K_DBG_SNOC, "snoc device resumed\n");
 
 	return ret;
-- 
2.7.4



From pillair at codeaurora.org  Tue Jul 21 13:14:24 2020
From: pillair at codeaurora.org (Rakesh Pillai)
Date: Tue, 21 Jul 2020 22:44:24 +0530
Subject: [RFC 5/7] ath10k: Handle the rx packet processing in thread
In-Reply-To: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
References: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
Message-ID: <1595351666-28193-6-git-send-email-pillair@codeaurora.org>

Add the support to handle the receive packet and
the tx completion processing in a thread context
if the feature has been enabled via module parameter.

Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.1-01040-QCAHLSWMTPLZ-1

Signed-off-by: Rakesh Pillai <pillair at codeaurora.org>
---
 drivers/net/wireless/ath/ath10k/core.c   |  8 ++++++
 drivers/net/wireless/ath/ath10k/core.h   |  4 +++
 drivers/net/wireless/ath/ath10k/htt.h    |  2 ++
 drivers/net/wireless/ath/ath10k/htt_rx.c | 46 +++++++++++++++++++++++++++-----
 drivers/net/wireless/ath/ath10k/snoc.c   | 12 +++++++--
 5 files changed, 64 insertions(+), 8 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 2b520a0..4064fa2 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -668,6 +668,14 @@ static unsigned int ath10k_core_get_fw_feature_str(char *buf,
 	return scnprintf(buf, buf_len, "%s", ath10k_core_fw_feature_str[feat]);
 }
 
+void ath10k_core_thread_post_event(struct ath10k_thread *thread,
+				   enum ath10k_thread_events event)
+{
+	set_bit(event, thread->event_flags);
+	wake_up(&thread->wait_q);
+}
+EXPORT_SYMBOL(ath10k_core_thread_post_event);
+
 int ath10k_core_thread_shutdown(struct ath10k *ar,
 				struct ath10k_thread *thread)
 {
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 59bdf11..596d31b 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -974,6 +974,8 @@ struct ath10k_bus_params {
 
 enum ath10k_thread_events {
 	ATH10K_THREAD_EVENT_SHUTDOWN,
+	ATH10K_THREAD_EVENT_RX_POST,
+	ATH10K_THREAD_EVENT_TX_POST,
 	ATH10K_THREAD_EVENT_MAX,
 };
 
@@ -1294,6 +1296,8 @@ static inline bool ath10k_peer_stats_enabled(struct ath10k *ar)
 
 extern unsigned long ath10k_coredump_mask;
 
+void ath10k_core_thread_post_event(struct ath10k_thread *thread,
+				   enum ath10k_thread_events event);
 int ath10k_core_thread_shutdown(struct ath10k *ar,
 				struct ath10k_thread *thread);
 int ath10k_core_thread_init(struct ath10k *ar,
diff --git a/drivers/net/wireless/ath/ath10k/htt.h b/drivers/net/wireless/ath/ath10k/htt.h
index cad5949..e3cb723 100644
--- a/drivers/net/wireless/ath/ath10k/htt.h
+++ b/drivers/net/wireless/ath/ath10k/htt.h
@@ -1970,6 +1970,8 @@ struct ath10k_htt {
 		spinlock_t lock;
 	} rx_ring;
 
+	/* Protects access to in order indication queue */
+	spinlock_t rx_in_ord_q_lock;
 	unsigned int prefetch_len;
 
 	/* Protects access to pending_tx, num_pending_tx */
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index a4a6618..becbd56 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -796,6 +796,7 @@ int ath10k_htt_rx_alloc(struct ath10k_htt *htt)
 	timer_setup(timer, ath10k_htt_rx_ring_refill_retry, 0);
 
 	spin_lock_init(&htt->rx_ring.lock);
+	spin_lock_init(&htt->rx_in_ord_q_lock);
 
 	htt->rx_ring.fill_cnt = 0;
 	htt->rx_ring.sw_rd_idx.msdu_payld = 0;
@@ -2702,10 +2703,17 @@ static void ath10k_htt_rx_tx_compl_ind(struct ath10k *ar,
 		 */
 		if (ar->bus_param.dev_type == ATH10K_DEV_TYPE_HL) {
 			ath10k_txrx_tx_unref(htt, &tx_done);
-		} else if (!kfifo_put(&htt->txdone_fifo, tx_done)) {
-			ath10k_warn(ar, "txdone fifo overrun, msdu_id %d status %d\n",
-				    tx_done.msdu_id, tx_done.status);
-			ath10k_txrx_tx_unref(htt, &tx_done);
+		} else {
+			if (!kfifo_put(&htt->txdone_fifo, tx_done)) {
+				ath10k_warn(ar, "txdone fifo overrun, msdu_id %d status %d\n",
+					    tx_done.msdu_id, tx_done.status);
+				ath10k_txrx_tx_unref(htt, &tx_done);
+				continue;
+			}
+			if (ar->rx_thread_enable)
+				ath10k_core_thread_post_event(
+					&ar->rx_thread,
+					ATH10K_THREAD_EVENT_TX_POST);
 		}
 	}
 
@@ -3903,7 +3911,16 @@ 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);
+		if (!ar->rx_thread_enable) {
+			skb_queue_tail(&htt->rx_in_ord_compl_q, skb);
+		} else {
+			spin_lock_bh(&htt->rx_in_ord_q_lock);
+			skb_queue_tail(&htt->rx_in_ord_compl_q, skb);
+			spin_unlock_bh(&htt->rx_in_ord_q_lock);
+			ath10k_core_thread_post_event(
+				&ar->rx_thread,
+				ATH10K_THREAD_EVENT_RX_POST);
+		}
 		return false;
 	}
 	case HTT_T2H_MSG_TYPE_TX_CREDIT_UPDATE_IND: {
@@ -4032,6 +4049,23 @@ int ath10k_htt_rx_hl_indication(struct ath10k *ar, int budget)
 }
 EXPORT_SYMBOL(ath10k_htt_rx_hl_indication);
 
+static inline struct sk_buff *
+ath10k_htt_dequeue_in_ord_q(struct ath10k_htt *htt)
+{
+	struct ath10k *ar = htt->ar;
+	struct sk_buff *skb = NULL;
+
+	if (ar->rx_thread_enable) {
+		spin_lock_bh(&htt->rx_in_ord_q_lock);
+		skb = skb_dequeue(&htt->rx_in_ord_compl_q);
+		spin_unlock_bh(&htt->rx_in_ord_q_lock);
+	} else {
+		skb = skb_dequeue(&htt->rx_in_ord_compl_q);
+	}
+
+	return skb;
+}
+
 int ath10k_htt_txrx_compl_task(struct ath10k *ar, int budget)
 {
 	struct ath10k_htt *htt = &ar->htt;
@@ -4053,7 +4087,7 @@ int ath10k_htt_txrx_compl_task(struct ath10k *ar, int budget)
 		goto exit;
 	}
 
-	while ((skb = skb_dequeue(&htt->rx_in_ord_compl_q))) {
+	while ((skb = ath10k_htt_dequeue_in_ord_q(htt))) {
 		spin_lock_bh(&htt->rx_ring.lock);
 		ret = ath10k_htt_rx_in_ord_ind(ar, skb);
 		spin_unlock_bh(&htt->rx_ring.lock);
diff --git a/drivers/net/wireless/ath/ath10k/snoc.c b/drivers/net/wireless/ath/ath10k/snoc.c
index f01725b..3eb5eac 100644
--- a/drivers/net/wireless/ath/ath10k/snoc.c
+++ b/drivers/net/wireless/ath/ath10k/snoc.c
@@ -920,6 +920,7 @@ int ath10k_snoc_rx_thread_loop(void *data)
 	struct ath10k_thread *rx_thread = data;
 	struct ath10k *ar = rx_thread->ar;
 	bool shutdown = false;
+	u32 thread_budget = 8192;
 
 	ath10k_dbg(ar, ATH10K_DBG_SNOC, "rx thread started\n");
 	set_user_nice(current, -1);
@@ -927,8 +928,14 @@ int ath10k_snoc_rx_thread_loop(void *data)
 	while (!shutdown) {
 		wait_event_interruptible(
 			rx_thread->wait_q,
-			(test_bit(ATH10K_THREAD_EVENT_SHUTDOWN,
+			(test_and_clear_bit(ATH10K_THREAD_EVENT_RX_POST,
+					    rx_thread->event_flags) ||
+			 test_and_clear_bit(ATH10K_THREAD_EVENT_TX_POST,
+					    rx_thread->event_flags) ||
+			 test_bit(ATH10K_THREAD_EVENT_SHUTDOWN,
 				  rx_thread->event_flags)));
+
+		ath10k_htt_txrx_compl_task(ar, thread_budget);
 		if (test_and_clear_bit(ATH10K_THREAD_EVENT_SHUTDOWN,
 				       rx_thread->event_flags))
 			shutdown = true;
@@ -1235,7 +1242,8 @@ static int ath10k_snoc_napi_poll(struct napi_struct *ctx, int budget)
 			ath10k_ce_enable_interrupt(ar, ce_id);
 		}
 
-	done = ath10k_htt_txrx_compl_task(ar, budget);
+	if (!ar->rx_thread_enable)
+		done = ath10k_htt_txrx_compl_task(ar, budget);
 
 	if (done < budget)
 		napi_complete(ctx);
-- 
2.7.4



From pillair at codeaurora.org  Tue Jul 21 13:14:20 2020
From: pillair at codeaurora.org (Rakesh Pillai)
Date: Tue, 21 Jul 2020 22:44:20 +0530
Subject: [RFC 1/7] mac80211: Add check for napi handle before WARN_ON
In-Reply-To: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
References: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
Message-ID: <1595351666-28193-2-git-send-email-pillair@codeaurora.org>

The function ieee80211_rx_napi can be now called
from a thread context as well, with napi context
being NULL.

Hence add the napi context check before giving out
a warning for softirq count being 0.

Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.1-01040-QCAHLSWMTPLZ-1

Signed-off-by: Rakesh Pillai <pillair at codeaurora.org>
---
 net/mac80211/rx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index a88ab6f..1e703f1 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -4652,7 +4652,7 @@ void ieee80211_rx_napi(struct ieee80211_hw *hw, struct ieee80211_sta *pubsta,
 	struct ieee80211_supported_band *sband;
 	struct ieee80211_rx_status *status = IEEE80211_SKB_RXCB(skb);
 
-	WARN_ON_ONCE(softirq_count() == 0);
+	WARN_ON_ONCE(napi && softirq_count() == 0);
 
 	if (WARN_ON(status->band >= NUM_NL80211_BANDS))
 		goto drop;
-- 
2.7.4



From pillair at codeaurora.org  Tue Jul 21 13:14:25 2020
From: pillair at codeaurora.org (Rakesh Pillai)
Date: Tue, 21 Jul 2020 22:44:25 +0530
Subject: [RFC 6/7] ath10k: Add deliver to stack from thread context
In-Reply-To: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
References: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
Message-ID: <1595351666-28193-7-git-send-email-pillair@codeaurora.org>

When the receive packets are submitted to the stack
from a thread context, the NAPI handle should be passed
as NULL to the function ieee80211_rx_napi. This will
make sure that the packets are submitted to stack via
non-napi method

Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.1-01040-QCAHLSWMTPLZ-1

Signed-off-by: Rakesh Pillai <pillair at codeaurora.org>
---
 drivers/net/wireless/ath/ath10k/htt_rx.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index becbd56..85c169c 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -1321,7 +1321,10 @@ static void ath10k_process_rx(struct ath10k *ar, struct sk_buff *skb)
 	trace_ath10k_rx_hdr(ar, skb->data, skb->len);
 	trace_ath10k_rx_payload(ar, skb->data, skb->len);
 
-	ieee80211_rx_napi(ar->hw, NULL, skb, &ar->napi);
+	if (in_serving_softirq())
+		ieee80211_rx_napi(ar->hw, NULL, skb, &ar->napi);
+	else
+		ieee80211_rx_napi(ar->hw, NULL, skb, NULL);
 }
 
 static int ath10k_htt_rx_nwifi_hdrlen(struct ath10k *ar,
-- 
2.7.4



From andrew at lunn.ch  Tue Jul 21 13:25:14 2020
From: andrew at lunn.ch (Andrew Lunn)
Date: Tue, 21 Jul 2020 19:25:14 +0200
Subject: [RFC 0/7] Add support to process rx packets in thread
In-Reply-To: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
References: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
Message-ID: <20200721172514.GT1339445@lunn.ch>

On Tue, Jul 21, 2020 at 10:44:19PM +0530, Rakesh Pillai wrote:
> NAPI gets scheduled on the CPU core which got the
> interrupt. The linux scheduler cannot move it to a
> different core, even if the CPU on which NAPI is running
> is heavily loaded. This can lead to degraded wifi
> performance when running traffic at peak data rates.
> 
> A thread on the other hand can be moved to different
> CPU cores, if the one on which its running is heavily
> loaded. During high incoming data traffic, this gives
> better performance, since the thread can be moved to a
> less loaded or sometimes even a more powerful CPU core
> to account for the required CPU performance in order
> to process the incoming packets.
> 
> This patch series adds the support to use a high priority
> thread to process the incoming packets, as opposed to
> everything being done in NAPI context.

I don't see why this problem is limited to the ath10k driver. I expect
it applies to all drivers using NAPI. So shouldn't you be solving this
in the NAPI core? Allow a driver to request the NAPI core uses a
thread?

	Andrew


From f.fainelli at gmail.com  Tue Jul 21 14:05:03 2020
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Tue, 21 Jul 2020 11:05:03 -0700
Subject: [RFC 0/7] Add support to process rx packets in thread
In-Reply-To: <20200721172514.GT1339445@lunn.ch>
References: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
 <20200721172514.GT1339445@lunn.ch>
Message-ID: <f6d93d76-9e59-c257-9318-31c71df28018@gmail.com>

On 7/21/20 10:25 AM, Andrew Lunn wrote:
> On Tue, Jul 21, 2020 at 10:44:19PM +0530, Rakesh Pillai wrote:
>> NAPI gets scheduled on the CPU core which got the
>> interrupt. The linux scheduler cannot move it to a
>> different core, even if the CPU on which NAPI is running
>> is heavily loaded. This can lead to degraded wifi
>> performance when running traffic at peak data rates.
>>
>> A thread on the other hand can be moved to different
>> CPU cores, if the one on which its running is heavily
>> loaded. During high incoming data traffic, this gives
>> better performance, since the thread can be moved to a
>> less loaded or sometimes even a more powerful CPU core
>> to account for the required CPU performance in order
>> to process the incoming packets.
>>
>> This patch series adds the support to use a high priority
>> thread to process the incoming packets, as opposed to
>> everything being done in NAPI context.
> 
> I don't see why this problem is limited to the ath10k driver. I expect
> it applies to all drivers using NAPI. So shouldn't you be solving this
> in the NAPI core? Allow a driver to request the NAPI core uses a
> thread?

What's more, you should be able to configure interrupt affinity to steer
RX processing onto a desired CPU core, is not that working for you somehow?
-- 
Florian


From rmanohar at codeaurora.org  Tue Jul 21 17:53:19 2020
From: rmanohar at codeaurora.org (Rajkumar Manoharan)
Date: Tue, 21 Jul 2020 14:53:19 -0700
Subject: [RFC 2/7] ath10k: Add support to process rx packet in thread
In-Reply-To: <1595351666-28193-3-git-send-email-pillair@codeaurora.org>
References: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
 <1595351666-28193-3-git-send-email-pillair@codeaurora.org>
Message-ID: <13573549c277b34d4c87c471ff1a7060@codeaurora.org>

On 2020-07-21 10:14, Rakesh Pillai wrote:
> NAPI instance gets scheduled on a CPU core on which
> the IRQ was triggered. The processing of rx packets
> can be CPU intensive and since NAPI cannot be moved
> to a different CPU core, to get better performance,
> its better to move the gist of rx packet processing
> in a high priority thread.
> 
> Add the init/deinit part for a thread to process the
> receive packets.
> 
IMHO this defeat the whole purpose of NAPI. Originally in ath10k
irq processing happened in tasklet (high priority) context which in
turn push more data to net core even though net is unable to process
driver data as both happen in different context (fast producer - slow 
consumer)
issue. Why can't CPU governor schedule the interrupts in less loaded CPU 
core?
Otherwise you can play with different RPS and affinity settings to meet 
your
requirement.

IMO introducing high priority tasklets/threads is not viable solution.

-Rajkumar


From David.Laight at ACULAB.COM  Wed Jul 22 05:12:42 2020
From: David.Laight at ACULAB.COM (David Laight)
Date: Wed, 22 Jul 2020 09:12:42 +0000
Subject: [RFC 0/7] Add support to process rx packets in thread
In-Reply-To: <20200721172514.GT1339445@lunn.ch>
References: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
 <20200721172514.GT1339445@lunn.ch>
Message-ID: <9fb3d3bd8d944a649cbe828fddca1bc1@AcuMS.aculab.com>

From: Andrew Lunn
> Sent: 21 July 2020 18:25
> 
> On Tue, Jul 21, 2020 at 10:44:19PM +0530, Rakesh Pillai wrote:
> > NAPI gets scheduled on the CPU core which got the
> > interrupt. The linux scheduler cannot move it to a
> > different core, even if the CPU on which NAPI is running
> > is heavily loaded. This can lead to degraded wifi
> > performance when running traffic at peak data rates.
> >
> > A thread on the other hand can be moved to different
> > CPU cores, if the one on which its running is heavily
> > loaded. During high incoming data traffic, this gives
> > better performance, since the thread can be moved to a
> > less loaded or sometimes even a more powerful CPU core
> > to account for the required CPU performance in order
> > to process the incoming packets.
> >
> > This patch series adds the support to use a high priority
> > thread to process the incoming packets, as opposed to
> > everything being done in NAPI context.
> 
> I don't see why this problem is limited to the ath10k driver. I expect
> it applies to all drivers using NAPI. So shouldn't you be solving this
> in the NAPI core? Allow a driver to request the NAPI core uses a
> thread?

It's not just NAPI the problem is with the softint processing.
I suspect a lot of systems would work better if it ran as
a (highish priority) kernel thread.

I've had to remove the main locks from a multi-threaded application
and replace them with atomic counters.
Consider what happens when the threads remove items from a shared
work list.
The code looks like:
	mutex_enter();
	remove_item_from_list();
	mutex_exit().
The mutex is only held for a few instructions, so while you'd expect
the cache line to be 'hot' you wouldn't get real contention.
However the following scenarios happen:
1) An ethernet interrupt happens while the mutex is held.
   This stops the other threads until all the softint processing
   has finished.
2) An ethernet interrupt (and softint) runs on a thread that is
   waiting for the mutex.
   (Or on the cpu that the thread's processor affinity ties it to.)
   In this case the 'fair' (ticket) mutex code won't let any other
   thread acquire the mutex.
   So again everything stops until the softints all complete.

The second one is also a problem when trying to wake up all
the threads (eg after adding a lot of items to the list).
The ticket locks force them to wake in order, but
sometimes the 'thundering herd' would work better.

IIRC this is actually worse for processes running under the RT
scheduler (without CONFIG_PREEMPT) because the they are almost
always scheduled on the same cpu they ran on last.
If it is busy, but cannot be pre-empted, they are not moved
to an idle cpu.
   
To confound things there is a very broken workaround for broken
hardware in the driver for the e1000 interface on (at least)
Ivy Bridge cpu that can cause the driver to spin for a very
long time (IIRC milliseconds) whenever it has to write to a
MAC register (ie on every transmit setup).

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)



From nbd at nbd.name  Wed Jul 22 08:27:42 2020
From: nbd at nbd.name (Felix Fietkau)
Date: Wed, 22 Jul 2020 14:27:42 +0200
Subject: [RFC 2/7] ath10k: Add support to process rx packet in thread
In-Reply-To: <13573549c277b34d4c87c471ff1a7060@codeaurora.org>
References: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
 <1595351666-28193-3-git-send-email-pillair@codeaurora.org>
 <13573549c277b34d4c87c471ff1a7060@codeaurora.org>
Message-ID: <d79ae05e-e75a-de2f-f2e3-bc73637e1501@nbd.name>

On 2020-07-21 23:53, Rajkumar Manoharan wrote:
> On 2020-07-21 10:14, Rakesh Pillai wrote:
>> NAPI instance gets scheduled on a CPU core on which
>> the IRQ was triggered. The processing of rx packets
>> can be CPU intensive and since NAPI cannot be moved
>> to a different CPU core, to get better performance,
>> its better to move the gist of rx packet processing
>> in a high priority thread.
>> 
>> Add the init/deinit part for a thread to process the
>> receive packets.
>> 
> IMHO this defeat the whole purpose of NAPI. Originally in ath10k
> irq processing happened in tasklet (high priority) context which in
> turn push more data to net core even though net is unable to process
> driver data as both happen in different context (fast producer - slow 
> consumer)
> issue. Why can't CPU governor schedule the interrupts in less loaded CPU 
> core?
> Otherwise you can play with different RPS and affinity settings to meet 
> your
> requirement.
> 
> IMO introducing high priority tasklets/threads is not viable solution.
I'm beginning to think that the main problem with NAPI here is that the
work done by poll functions on 802.11 drivers is significantly more CPU
intensive compared to ethernet drivers, possibly more than what NAPI was
designed for.

I'm considering testing a different approach (with mt76 initially):
- Add a mac80211 rx function that puts processed skbs into a list
instead of handing them to the network stack directly.
- Move all rx processing to a high priority thread, keep a driver
internal queue for fully processed packets.
- Schedule NAPI poll on completion.
- NAPI poll function pulls from the internal queue and passes to the
network stack.

With this approach, the network stack retains some control over the
processing rate of rx packets, while the scheduler can move the CPU
intensive processing around to where it fits best.

What do you think?

- Felix


From johannes at sipsolutions.net  Wed Jul 22 08:55:06 2020
From: johannes at sipsolutions.net (Johannes Berg)
Date: Wed, 22 Jul 2020 14:55:06 +0200
Subject: [RFC 2/7] ath10k: Add support to process rx packet in thread
In-Reply-To: <d79ae05e-e75a-de2f-f2e3-bc73637e1501@nbd.name>
References: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
 <1595351666-28193-3-git-send-email-pillair@codeaurora.org>
 <13573549c277b34d4c87c471ff1a7060@codeaurora.org>
 <d79ae05e-e75a-de2f-f2e3-bc73637e1501@nbd.name>
Message-ID: <04d7301d5ad7555a0377c7df530ad8522fc00f77.camel@sipsolutions.net>

On Wed, 2020-07-22 at 14:27 +0200, Felix Fietkau wrote:

> I'm considering testing a different approach (with mt76 initially):
> - Add a mac80211 rx function that puts processed skbs into a list
> instead of handing them to the network stack directly.

Would this be *after* all the mac80211 processing, i.e. in place of the
rx-up-to-stack?

johannes



From johannes at sipsolutions.net  Wed Jul 22 08:56:00 2020
From: johannes at sipsolutions.net (Johannes Berg)
Date: Wed, 22 Jul 2020 14:56:00 +0200
Subject: [RFC 1/7] mac80211: Add check for napi handle before WARN_ON
In-Reply-To: <1595351666-28193-2-git-send-email-pillair@codeaurora.org>
References: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
 <1595351666-28193-2-git-send-email-pillair@codeaurora.org>
Message-ID: <0dbdef912f9d61521011f638200fd451a3530568.camel@sipsolutions.net>

On Tue, 2020-07-21 at 22:44 +0530, Rakesh Pillai wrote:
> The function ieee80211_rx_napi can be now called
> from a thread context as well, with napi context
> being NULL.
> 
> Hence add the napi context check before giving out
> a warning for softirq count being 0.
> 
> Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.1-01040-QCAHLSWMTPLZ-1
> 
> Signed-off-by: Rakesh Pillai <pillair at codeaurora.org>
> ---
>  net/mac80211/rx.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
> index a88ab6f..1e703f1 100644
> --- a/net/mac80211/rx.c
> +++ b/net/mac80211/rx.c
> @@ -4652,7 +4652,7 @@ void ieee80211_rx_napi(struct ieee80211_hw *hw, struct ieee80211_sta *pubsta,
>  	struct ieee80211_supported_band *sband;
>  	struct ieee80211_rx_status *status = IEEE80211_SKB_RXCB(skb);
>  
> -	WARN_ON_ONCE(softirq_count() == 0);
> +	WARN_ON_ONCE(napi && softirq_count() == 0);

FWIW, I'm pretty sure this is incorrect - we make assumptions on
softirqs being disabled in mac80211 for serialization and in place of
some locking, I believe.

johannes



From nbd at nbd.name  Wed Jul 22 09:00:30 2020
From: nbd at nbd.name (Felix Fietkau)
Date: Wed, 22 Jul 2020 15:00:30 +0200
Subject: [RFC 2/7] ath10k: Add support to process rx packet in thread
In-Reply-To: <04d7301d5ad7555a0377c7df530ad8522fc00f77.camel@sipsolutions.net>
References: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
 <1595351666-28193-3-git-send-email-pillair@codeaurora.org>
 <13573549c277b34d4c87c471ff1a7060@codeaurora.org>
 <d79ae05e-e75a-de2f-f2e3-bc73637e1501@nbd.name>
 <04d7301d5ad7555a0377c7df530ad8522fc00f77.camel@sipsolutions.net>
Message-ID: <1f2726ff-8ba9-5278-0ec6-b80be475ea98@nbd.name>

On 2020-07-22 14:55, Johannes Berg wrote:
> On Wed, 2020-07-22 at 14:27 +0200, Felix Fietkau wrote:
> 
>> I'm considering testing a different approach (with mt76 initially):
>> - Add a mac80211 rx function that puts processed skbs into a list
>> instead of handing them to the network stack directly.
> 
> Would this be *after* all the mac80211 processing, i.e. in place of the
> rx-up-to-stack?
Yes, it would run all the rx handlers normally and then put the
resulting skbs into a list instead of calling netif_receive_skb or
napi_gro_frags.

- Felix


From leon at georgemail.eu  Wed Jul 22 10:18:12 2020
From: leon at georgemail.eu (Leon M. George)
Date: Wed, 22 Jul 2020 16:18:12 +0200
Subject: duplicate authentications / excessive missing ACKs / deauth due
 to inactivity timer
Message-ID: <20200722161812.329d7a10@brot>

Hi :-)

I've encountered connection issues that appear to be strongly related to the
problem in this thread [1] (found via the arch linux bug tracker [2]).

Symptoms:
ap: "disconnected due to excessive missing ACKs"
station: "No beacon heard and the time event is over already..."

Using a monitoring interface on the AP i was able to confirm that the beacon is
indeed not being sent at any time.

I've found a configuration that reliably produces this state
("error state" from here on):
If any number of mesh (or adhoc with ct) points are configured alongside any
number of ordinary APs, this issue starts appearing.
The mesh connections appear to be working correctly in the error state.

I tested various combinations of openwrt-19.xx and openwrt-trunk
with ath10k/ath10k-ct - all were affected.
Aligning with my vague memory, a user on the openwrt forum reports the issue isn't
present in openwrt-18.xx [3].

About the ruling out client issues:
My employer is operating installations with multiple hundreds of ath10k access
points.
We couldn't identify the source of the issue at first when we encountered it in
our live setup and received unsolicited reports from basically every
installation.
As far as we can tell, no client is able to connect in the error state.
We've had our users confirm the bug for
  - Apple phones/tablets/macbooks
  - Samsung phones, laptops
  - computers with Intel/Realtek/AzureWave-hardware.

I hope this info is helpful.

kind regards,
Leon George

[1] https://www.mail-archive.com/ath10k at lists.infradead.org/msg11599.html
[2] https://bugs.archlinux.org/task/58457
[3] https://forum.openwrt.org/t/wifi-connectivity-issues-with-ath10k/67779


From greearb at candelatech.com  Wed Jul 22 10:27:16 2020
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 22 Jul 2020 07:27:16 -0700
Subject: duplicate authentications / excessive missing ACKs / deauth due
 to inactivity timer
In-Reply-To: <20200722161812.329d7a10@brot>
References: <20200722161812.329d7a10@brot>
Message-ID: <cdba7890-62e4-4d99-bd0f-f1d458a4adc7@candelatech.com>

On 7/22/20 7:18 AM, Leon M. George wrote:
> Hi :-)
> 
> I've encountered connection issues that appear to be strongly related to the
> problem in this thread [1] (found via the arch linux bug tracker [2]).

If this is ath10k-ct only problem, plz don't bother this list and send to just me
and/or add to ath10k-ct bugtracker on github.

If it does affect upstream ath10k too, then that would be valid for this mailing
list.

Thanks,
Ben

> 
> Symptoms:
> ap: "disconnected due to excessive missing ACKs"
> station: "No beacon heard and the time event is over already..."
> 
> Using a monitoring interface on the AP i was able to confirm that the beacon is
> indeed not being sent at any time.
> 
> I've found a configuration that reliably produces this state
> ("error state" from here on):
> If any number of mesh (or adhoc with ct) points are configured alongside any
> number of ordinary APs, this issue starts appearing.
> The mesh connections appear to be working correctly in the error state.
> 
> I tested various combinations of openwrt-19.xx and openwrt-trunk
> with ath10k/ath10k-ct - all were affected.
> Aligning with my vague memory, a user on the openwrt forum reports the issue isn't
> present in openwrt-18.xx [3].
> 
> About the ruling out client issues:
> My employer is operating installations with multiple hundreds of ath10k access
> points.
> We couldn't identify the source of the issue at first when we encountered it in
> our live setup and received unsolicited reports from basically every
> installation.
> As far as we can tell, no client is able to connect in the error state.
> We've had our users confirm the bug for
>    - Apple phones/tablets/macbooks
>    - Samsung phones, laptops
>    - computers with Intel/Realtek/AzureWave-hardware.
> 
> I hope this info is helpful.
> 
> kind regards,
> Leon George
> 
> [1] https://www.mail-archive.com/ath10k at lists.infradead.org/msg11599.html
> [2] https://bugs.archlinux.org/task/58457
> [3] https://forum.openwrt.org/t/wifi-connectivity-issues-with-ath10k/67779
> 
> _______________________________________________
> 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 leon at georgemail.eu  Wed Jul 22 12:04:42 2020
From: leon at georgemail.eu (Leon M. George)
Date: Wed, 22 Jul 2020 18:04:42 +0200
Subject: duplicate authentications / excessive missing ACKs / deauth due
 to inactivity timer
In-Reply-To: <cdba7890-62e4-4d99-bd0f-f1d458a4adc7@candelatech.com>
References: <20200722161812.329d7a10@brot>
 <cdba7890-62e4-4d99-bd0f-f1d458a4adc7@candelatech.com>
Message-ID: <20200722180442.03b40f01@brot>

Hi Ben,

I was unclear in my last email.
Re-phrasing from my openwrt forum post:

I've tested various combinations of openwrt-trunk (now and early March) / 19.07, ath10k stock / ct driver, and stock / ct firmware.

regards,
Leon


On Wed, 22 Jul 2020 07:27:16 -0700
Ben Greear <greearb at candelatech.com> wrote:

> On 7/22/20 7:18 AM, Leon M. George wrote:
> > Hi :-)
> > 
> > I've encountered connection issues that appear to be strongly
> > related to the problem in this thread [1] (found via the arch linux
> > bug tracker [2]).
> 
> If this is ath10k-ct only problem, plz don't bother this list and
> send to just me and/or add to ath10k-ct bugtracker on github.
> 
> If it does affect upstream ath10k too, then that would be valid for
> this mailing list.
> 
> Thanks,
> Ben
> 


From kuba at kernel.org  Wed Jul 22 12:20:01 2020
From: kuba at kernel.org (Jakub Kicinski)
Date: Wed, 22 Jul 2020 09:20:01 -0700
Subject: [RFC 0/7] Add support to process rx packets in thread
In-Reply-To: <20200721172514.GT1339445@lunn.ch>
References: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
 <20200721172514.GT1339445@lunn.ch>
Message-ID: <20200722092001.62f3772c@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>

On Tue, 21 Jul 2020 19:25:14 +0200 Andrew Lunn wrote:
> On Tue, Jul 21, 2020 at 10:44:19PM +0530, Rakesh Pillai wrote:
> > NAPI gets scheduled on the CPU core which got the
> > interrupt. The linux scheduler cannot move it to a
> > different core, even if the CPU on which NAPI is running
> > is heavily loaded. This can lead to degraded wifi
> > performance when running traffic at peak data rates.
> > 
> > A thread on the other hand can be moved to different
> > CPU cores, if the one on which its running is heavily
> > loaded. During high incoming data traffic, this gives
> > better performance, since the thread can be moved to a
> > less loaded or sometimes even a more powerful CPU core
> > to account for the required CPU performance in order
> > to process the incoming packets.
> > 
> > This patch series adds the support to use a high priority
> > thread to process the incoming packets, as opposed to
> > everything being done in NAPI context.  
> 
> I don't see why this problem is limited to the ath10k driver. I expect
> it applies to all drivers using NAPI. So shouldn't you be solving this
> in the NAPI core? Allow a driver to request the NAPI core uses a
> thread?

Agreed, this is a problem we have with all drivers today.
We see seriously sub-optimal behavior in data center workloads, 
because kernel overloads the cores doing packet processing.

I think the fix may actually be in the scheduler. AFAIU the scheduler
counts the softIRQ time towards the interrupted process, and on top
of that tries to move processes to the cores handling their IO. In the
end the configuration which works somewhat okay is when each core has
its own IRQ and queues, which is seriously sub-optimal.


From info at controlypotencia.com  Wed Jul 22 16:08:32 2020
From: info at controlypotencia.com (Peter Wong)
Date: Wed, 22 Jul 2020 22:08:32 +0200
Subject: Investment opportunity
Message-ID: <mailman.1.1595448723.957.ath10k@lists.infradead.org>

Greetings

I am contacting you for a proffer to invest in any profitable business in your country.

We offer a quick loan at low interest rate, if you are interested please reply to peterwonghsbl at naver.com for more details.

Sincerely: Peter Wong


From rmanohar at codeaurora.org  Thu Jul 23 02:09:49 2020
From: rmanohar at codeaurora.org (Rajkumar Manoharan)
Date: Wed, 22 Jul 2020 23:09:49 -0700
Subject: [RFC 2/7] ath10k: Add support to process rx packet in thread
In-Reply-To: <1f2726ff-8ba9-5278-0ec6-b80be475ea98@nbd.name>
References: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
 <1595351666-28193-3-git-send-email-pillair@codeaurora.org>
 <13573549c277b34d4c87c471ff1a7060@codeaurora.org>
 <d79ae05e-e75a-de2f-f2e3-bc73637e1501@nbd.name>
 <04d7301d5ad7555a0377c7df530ad8522fc00f77.camel@sipsolutions.net>
 <1f2726ff-8ba9-5278-0ec6-b80be475ea98@nbd.name>
Message-ID: <cd705bfc39721d5738fe1ee3d806a131@codeaurora.org>

On 2020-07-22 06:00, Felix Fietkau wrote:
> On 2020-07-22 14:55, Johannes Berg wrote:
>> On Wed, 2020-07-22 at 14:27 +0200, Felix Fietkau wrote:
>> 
>>> I'm considering testing a different approach (with mt76 initially):
>>> - Add a mac80211 rx function that puts processed skbs into a list
>>> instead of handing them to the network stack directly.
>> 
>> Would this be *after* all the mac80211 processing, i.e. in place of 
>> the
>> rx-up-to-stack?
> Yes, it would run all the rx handlers normally and then put the
> resulting skbs into a list instead of calling netif_receive_skb or
> napi_gro_frags.
> 
Felix,

This seems like split & batch processing. In past (ath9k), we observed 
some
behavioral differences between netif_rx and netif_receive_skb. The 
intermediate
queue in netif_rx changed not just performance but also time sensitive 
application
data. Agree that wireless stack processing might be heavier than 
ethernet packet
processing. If the hardware supports rx decap offload, NAPI processing 
shouldn't be
an issue. right?

-Rajkumar


From lkp at intel.com  Thu Jul 23 12:59:34 2020
From: lkp at intel.com (kernel test robot)
Date: Fri, 24 Jul 2020 00:59:34 +0800
Subject: [ath6kl:master] BUILD SUCCESS 806b0c3d5a24d87a7b37f0104cd1b30c2b04c15a
Message-ID: <5f19c1f6.JQnKMrBN5h019Xim%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git  master
branch HEAD: 806b0c3d5a24d87a7b37f0104cd1b30c2b04c15a  Add localversion-wireless-testing-ath

elapsed time: 4208m

configs tested: 101
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

arm                                 defconfig
arm                              allyesconfig
arm                              allmodconfig
arm                               allnoconfig
arm64                            allyesconfig
arm64                               defconfig
arm64                            allmodconfig
arm64                             allnoconfig
sh                               alldefconfig
mips                         bigsur_defconfig
arm                           sama5_defconfig
arm                           omap1_defconfig
mips                            e55_defconfig
arm                         s3c6400_defconfig
mips                       rbtx49xx_defconfig
arm                            u300_defconfig
ia64                             alldefconfig
i386                             allyesconfig
i386                                defconfig
i386                              debian-10.3
i386                              allnoconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                              allnoconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                              allnoconfig
m68k                           sun3_defconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
nios2                            allyesconfig
c6x                              allyesconfig
c6x                               allnoconfig
openrisc                         allyesconfig
nds32                               defconfig
nds32                             allnoconfig
csky                             allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
h8300                            allmodconfig
xtensa                              defconfig
arc                                 defconfig
arc                              allyesconfig
sh                               allmodconfig
sh                                allnoconfig
microblaze                        allnoconfig
openrisc                            defconfig
mips                             allyesconfig
mips                              allnoconfig
mips                             allmodconfig
parisc                            allnoconfig
parisc                              defconfig
parisc                           allyesconfig
parisc                           allmodconfig
powerpc                             defconfig
powerpc                          allyesconfig
powerpc                          rhel-kconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
i386                 randconfig-a003-20200723
i386                 randconfig-a005-20200723
i386                 randconfig-a004-20200723
i386                 randconfig-a006-20200723
i386                 randconfig-a002-20200723
i386                 randconfig-a001-20200723
i386                 randconfig-a016-20200723
i386                 randconfig-a013-20200723
i386                 randconfig-a012-20200723
i386                 randconfig-a015-20200723
i386                 randconfig-a011-20200723
i386                 randconfig-a014-20200723
x86_64               randconfig-a005-20200719
x86_64               randconfig-a002-20200719
x86_64               randconfig-a006-20200719
x86_64               randconfig-a001-20200719
x86_64               randconfig-a003-20200719
x86_64               randconfig-a004-20200719
riscv                            allyesconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                            allmodconfig
s390                             allyesconfig
s390                              allnoconfig
s390                             allmodconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
sparc64                             defconfig
sparc64                           allnoconfig
sparc64                          allyesconfig
sparc64                          allmodconfig
x86_64                    rhel-7.6-kselftests
x86_64                               rhel-8.3
x86_64                                  kexec
x86_64                                   rhel
x86_64                                    lkp
x86_64                              fedora-25

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From alan at znettelecom.net  Thu Jul 23 12:54:02 2020
From: alan at znettelecom.net (Steve lenka)
Date: Thu, 23 Jul 2020 18:54:02 +0200
Subject: DONATION OFFER
Message-ID: <E1jyeTg-0004bo-Va@srv01.znettelecom.net>

Hello, Donation of 1,000,000.00 GBP given to you by Steve & Lenka Thomson, This is to help fight against Corona Virus and help the poor people off the streets. send email for more details: stevelenkathomson12 at gmail.com
Steve & Lenka Thomson

-- 
L'absence de virus dans ce courrier ?lectronique a ?t? v?rifi?e par le logiciel antivirus Avast.
https://www.avast.com/antivirus



From pillair at codeaurora.org  Thu Jul 23 14:21:08 2020
From: pillair at codeaurora.org (Rakesh Pillai)
Date: Thu, 23 Jul 2020 23:51:08 +0530
Subject: [RFC 0/7] Add support to process rx packets in thread
In-Reply-To: <f6d93d76-9e59-c257-9318-31c71df28018@gmail.com>
References: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
 <20200721172514.GT1339445@lunn.ch>
 <f6d93d76-9e59-c257-9318-31c71df28018@gmail.com>
Message-ID: <002e01d6611e$0d8ac640$28a052c0$@codeaurora.org>



> -----Original Message-----
> From: Florian Fainelli <f.fainelli at gmail.com>
> Sent: Tuesday, July 21, 2020 11:35 PM
> To: Andrew Lunn <andrew at lunn.ch>; Rakesh Pillai <pillair at codeaurora.org>
> Cc: ath10k at lists.infradead.org; linux-wireless at vger.kernel.org; linux-
> kernel at vger.kernel.org; kvalo at codeaurora.org; johannes at sipsolutions.net;
> davem at davemloft.net; kuba at kernel.org; netdev at vger.kernel.org;
> dianders at chromium.org; evgreen at chromium.org
> Subject: Re: [RFC 0/7] Add support to process rx packets in thread
> 
> On 7/21/20 10:25 AM, Andrew Lunn wrote:
> > On Tue, Jul 21, 2020 at 10:44:19PM +0530, Rakesh Pillai wrote:
> >> NAPI gets scheduled on the CPU core which got the
> >> interrupt. The linux scheduler cannot move it to a
> >> different core, even if the CPU on which NAPI is running
> >> is heavily loaded. This can lead to degraded wifi
> >> performance when running traffic at peak data rates.
> >>
> >> A thread on the other hand can be moved to different
> >> CPU cores, if the one on which its running is heavily
> >> loaded. During high incoming data traffic, this gives
> >> better performance, since the thread can be moved to a
> >> less loaded or sometimes even a more powerful CPU core
> >> to account for the required CPU performance in order
> >> to process the incoming packets.
> >>
> >> This patch series adds the support to use a high priority
> >> thread to process the incoming packets, as opposed to
> >> everything being done in NAPI context.
> >
> > I don't see why this problem is limited to the ath10k driver. I expect
> > it applies to all drivers using NAPI. So shouldn't you be solving this
> > in the NAPI core? Allow a driver to request the NAPI core uses a
> > thread?
> 
> What's more, you should be able to configure interrupt affinity to steer
> RX processing onto a desired CPU core, is not that working for you
> somehow?

Hi Florian,
Yes, the affinity of IRQ does work for me.
But the affinity of IRQ does not happen runtime based on load.


> --
> Florian



From pillair at codeaurora.org  Thu Jul 23 14:25:06 2020
From: pillair at codeaurora.org (Rakesh Pillai)
Date: Thu, 23 Jul 2020 23:55:06 +0530
Subject: [RFC 2/7] ath10k: Add support to process rx packet in thread
In-Reply-To: <13573549c277b34d4c87c471ff1a7060@codeaurora.org>
References: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
 <1595351666-28193-3-git-send-email-pillair@codeaurora.org>
 <13573549c277b34d4c87c471ff1a7060@codeaurora.org>
Message-ID: <003001d6611e$9afa0cc0$d0ee2640$@codeaurora.org>



> -----Original Message-----
> From: Rajkumar Manoharan <rmanohar at codeaurora.org>
> Sent: Wednesday, July 22, 2020 3:23 AM
> To: Rakesh Pillai <pillair at codeaurora.org>
> Cc: ath10k at lists.infradead.org; linux-wireless at vger.kernel.org; linux-
> kernel at vger.kernel.org; kvalo at codeaurora.org; johannes at sipsolutions.net;
> davem at davemloft.net; kuba at kernel.org; netdev at vger.kernel.org;
> dianders at chromium.org; evgreen at chromium.org; linux-wireless-
> owner at vger.kernel.org
> Subject: Re: [RFC 2/7] ath10k: Add support to process rx packet in thread
> 
> On 2020-07-21 10:14, Rakesh Pillai wrote:
> > NAPI instance gets scheduled on a CPU core on which
> > the IRQ was triggered. The processing of rx packets
> > can be CPU intensive and since NAPI cannot be moved
> > to a different CPU core, to get better performance,
> > its better to move the gist of rx packet processing
> > in a high priority thread.
> >
> > Add the init/deinit part for a thread to process the
> > receive packets.
> >
> IMHO this defeat the whole purpose of NAPI. Originally in ath10k
> irq processing happened in tasklet (high priority) context which in
> turn push more data to net core even though net is unable to process
> driver data as both happen in different context (fast producer - slow
> consumer)
> issue. Why can't CPU governor schedule the interrupts in less loaded CPU
> core?
> Otherwise you can play with different RPS and affinity settings to meet
> your
> requirement.
> 
> IMO introducing high priority tasklets/threads is not viable solution.

Hi Rajkumar,
In linux, the IRQs are directed to the first core which is booted.
I see that all the IRQs are getting routed to CORE0 even if its heavily
loaded.

IRQ and NAPI are not under the scheduler's control, since it cannot be
moved.
NAPI is scheduled only on the same core as IRQ. But a thread can be moved
around by the scheduler based on the CPU load.
This is the reason I went ahead with using thread.

Affinity settings are static, and cannot be done runtime without any
downstream userspace entity.


> 
> -Rajkumar



From pillair at codeaurora.org  Thu Jul 23 14:26:18 2020
From: pillair at codeaurora.org (Rakesh Pillai)
Date: Thu, 23 Jul 2020 23:56:18 +0530
Subject: [RFC 1/7] mac80211: Add check for napi handle before WARN_ON
In-Reply-To: <0dbdef912f9d61521011f638200fd451a3530568.camel@sipsolutions.net>
References: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>	
 <1595351666-28193-2-git-send-email-pillair@codeaurora.org>
 <0dbdef912f9d61521011f638200fd451a3530568.camel@sipsolutions.net>
Message-ID: <003201d6611e$c54a1c90$4fde55b0$@codeaurora.org>



> -----Original Message-----
> From: Johannes Berg <johannes at sipsolutions.net>
> Sent: Wednesday, July 22, 2020 6:26 PM
> To: Rakesh Pillai <pillair at codeaurora.org>; ath10k at lists.infradead.org
> Cc: linux-wireless at vger.kernel.org; linux-kernel at vger.kernel.org;
> kvalo at codeaurora.org; davem at davemloft.net; kuba at kernel.org;
> netdev at vger.kernel.org; dianders at chromium.org; evgreen at chromium.org
> Subject: Re: [RFC 1/7] mac80211: Add check for napi handle before
> WARN_ON
> 
> On Tue, 2020-07-21 at 22:44 +0530, Rakesh Pillai wrote:
> > The function ieee80211_rx_napi can be now called
> > from a thread context as well, with napi context
> > being NULL.
> >
> > Hence add the napi context check before giving out
> > a warning for softirq count being 0.
> >
> > Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.1-01040-QCAHLSWMTPLZ-1
> >
> > Signed-off-by: Rakesh Pillai <pillair at codeaurora.org>
> > ---
> >  net/mac80211/rx.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
> > index a88ab6f..1e703f1 100644
> > --- a/net/mac80211/rx.c
> > +++ b/net/mac80211/rx.c
> > @@ -4652,7 +4652,7 @@ void ieee80211_rx_napi(struct ieee80211_hw
> *hw, struct ieee80211_sta *pubsta,
> >  	struct ieee80211_supported_band *sband;
> >  	struct ieee80211_rx_status *status = IEEE80211_SKB_RXCB(skb);
> >
> > -	WARN_ON_ONCE(softirq_count() == 0);
> > +	WARN_ON_ONCE(napi && softirq_count() == 0);
> 
> FWIW, I'm pretty sure this is incorrect - we make assumptions on
> softirqs being disabled in mac80211 for serialization and in place of
> some locking, I believe.
> 

I checked this, but let me double confirm.
But after this change, no packet is submitted from driver in a softirq context.
So ideally this should take care of serialization.


> johannes




From f.fainelli at gmail.com  Thu Jul 23 15:02:40 2020
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Thu, 23 Jul 2020 12:02:40 -0700
Subject: [RFC 0/7] Add support to process rx packets in thread
In-Reply-To: <002e01d6611e$0d8ac640$28a052c0$@codeaurora.org>
References: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
 <20200721172514.GT1339445@lunn.ch>
 <f6d93d76-9e59-c257-9318-31c71df28018@gmail.com>
 <002e01d6611e$0d8ac640$28a052c0$@codeaurora.org>
Message-ID: <fdedf787-1bb0-601c-0959-6f1bfb38e5d7@gmail.com>

On 7/23/20 11:21 AM, Rakesh Pillai wrote:
> 
> 
>> -----Original Message-----
>> From: Florian Fainelli <f.fainelli at gmail.com>
>> Sent: Tuesday, July 21, 2020 11:35 PM
>> To: Andrew Lunn <andrew at lunn.ch>; Rakesh Pillai <pillair at codeaurora.org>
>> Cc: ath10k at lists.infradead.org; linux-wireless at vger.kernel.org; linux-
>> kernel at vger.kernel.org; kvalo at codeaurora.org; johannes at sipsolutions.net;
>> davem at davemloft.net; kuba at kernel.org; netdev at vger.kernel.org;
>> dianders at chromium.org; evgreen at chromium.org
>> Subject: Re: [RFC 0/7] Add support to process rx packets in thread
>>
>> On 7/21/20 10:25 AM, Andrew Lunn wrote:
>>> On Tue, Jul 21, 2020 at 10:44:19PM +0530, Rakesh Pillai wrote:
>>>> NAPI gets scheduled on the CPU core which got the
>>>> interrupt. The linux scheduler cannot move it to a
>>>> different core, even if the CPU on which NAPI is running
>>>> is heavily loaded. This can lead to degraded wifi
>>>> performance when running traffic at peak data rates.
>>>>
>>>> A thread on the other hand can be moved to different
>>>> CPU cores, if the one on which its running is heavily
>>>> loaded. During high incoming data traffic, this gives
>>>> better performance, since the thread can be moved to a
>>>> less loaded or sometimes even a more powerful CPU core
>>>> to account for the required CPU performance in order
>>>> to process the incoming packets.
>>>>
>>>> This patch series adds the support to use a high priority
>>>> thread to process the incoming packets, as opposed to
>>>> everything being done in NAPI context.
>>>
>>> I don't see why this problem is limited to the ath10k driver. I expect
>>> it applies to all drivers using NAPI. So shouldn't you be solving this
>>> in the NAPI core? Allow a driver to request the NAPI core uses a
>>> thread?
>>
>> What's more, you should be able to configure interrupt affinity to steer
>> RX processing onto a desired CPU core, is not that working for you
>> somehow?
> 
> Hi Florian,
> Yes, the affinity of IRQ does work for me.
> But the affinity of IRQ does not happen runtime based on load.

It can if you also run irqbalance.
-- 
Florian


From johannes at sipsolutions.net  Thu Jul 23 16:06:46 2020
From: johannes at sipsolutions.net (Johannes Berg)
Date: Thu, 23 Jul 2020 22:06:46 +0200
Subject: [RFC 1/7] mac80211: Add check for napi handle before WARN_ON
In-Reply-To: <003201d6611e$c54a1c90$4fde55b0$@codeaurora.org>
References: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
 <1595351666-28193-2-git-send-email-pillair@codeaurora.org>
 <0dbdef912f9d61521011f638200fd451a3530568.camel@sipsolutions.net>
 <003201d6611e$c54a1c90$4fde55b0$@codeaurora.org>
Message-ID: <ce380ea1fd1f5db40a92f67673f070a1f88eee50.camel@sipsolutions.net>

On Thu, 2020-07-23 at 23:56 +0530, Rakesh Pillai wrote:

> > > -	WARN_ON_ONCE(softirq_count() == 0);
> > > +	WARN_ON_ONCE(napi && softirq_count() == 0);
> > 
> > FWIW, I'm pretty sure this is incorrect - we make assumptions on
> > softirqs being disabled in mac80211 for serialization and in place of
> > some locking, I believe.
> > 
> 
> I checked this, but let me double confirm.
> But after this change, no packet is submitted from driver in a softirq context.
> So ideally this should take care of serialization.

I'd guess that we have some reliance on BHs already being disabled, for
things like u64 sync updates, or whatnot. I mean, we did "rx_ni()" for a
reason ... Maybe lockdep can help catch some of the issues.

But couldn't you be in a thread and have BHs disabled too?

johannes



From lkp at intel.com  Thu Jul 23 18:00:13 2020
From: lkp at intel.com (kernel test robot)
Date: Fri, 24 Jul 2020 06:00:13 +0800
Subject: [ath6kl:ath-qca] BUILD SUCCESS
 6b77d3c5d824dc2eb48a4187ca9e786bccde0bf9
Message-ID: <5f1a086d.MV3Mw3LipzRVsL58%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git  ath-qca
branch HEAD: 6b77d3c5d824dc2eb48a4187ca9e786bccde0bf9  Merge branch 'ath-next' into ath-qca

elapsed time: 4509m

configs tested: 101
configs skipped: 1

The following configs have been built successfully.
More configs may be tested in the coming days.

arm                                 defconfig
arm                              allyesconfig
arm                              allmodconfig
arm                               allnoconfig
arm64                            allyesconfig
arm64                               defconfig
arm64                            allmodconfig
arm64                             allnoconfig
mips                  cavium_octeon_defconfig
mips                malta_qemu_32r6_defconfig
arm                        vexpress_defconfig
sh                             shx3_defconfig
arm                      integrator_defconfig
arm                         shannon_defconfig
powerpc                       ppc64_defconfig
arm                      footbridge_defconfig
s390                             alldefconfig
i386                             allyesconfig
i386                                defconfig
i386                              debian-10.3
i386                              allnoconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                              allnoconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                              allnoconfig
m68k                           sun3_defconfig
m68k                                defconfig
m68k                             allyesconfig
nds32                               defconfig
nds32                             allnoconfig
csky                             allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
h8300                            allmodconfig
xtensa                              defconfig
arc                                 defconfig
arc                              allyesconfig
sh                               allmodconfig
sh                                allnoconfig
microblaze                        allnoconfig
nios2                               defconfig
nios2                            allyesconfig
openrisc                            defconfig
c6x                              allyesconfig
c6x                               allnoconfig
openrisc                         allyesconfig
mips                             allyesconfig
mips                              allnoconfig
mips                             allmodconfig
parisc                            allnoconfig
parisc                              defconfig
parisc                           allyesconfig
parisc                           allmodconfig
powerpc                             defconfig
powerpc                          allyesconfig
powerpc                          rhel-kconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
i386                 randconfig-a001-20200719
i386                 randconfig-a006-20200719
i386                 randconfig-a002-20200719
i386                 randconfig-a005-20200719
i386                 randconfig-a003-20200719
i386                 randconfig-a004-20200719
i386                 randconfig-a015-20200719
i386                 randconfig-a011-20200719
i386                 randconfig-a016-20200719
i386                 randconfig-a012-20200719
i386                 randconfig-a013-20200719
i386                 randconfig-a014-20200719
x86_64               randconfig-a005-20200719
x86_64               randconfig-a002-20200719
x86_64               randconfig-a006-20200719
x86_64               randconfig-a001-20200719
x86_64               randconfig-a003-20200719
x86_64               randconfig-a004-20200719
riscv                            allyesconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                            allmodconfig
s390                             allyesconfig
s390                              allnoconfig
s390                             allmodconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
sparc64                             defconfig
sparc64                           allnoconfig
sparc64                          allyesconfig
sparc64                          allmodconfig
x86_64                    rhel-7.6-kselftests
x86_64                               rhel-8.3
x86_64                                  kexec
x86_64                                   rhel
x86_64                                    lkp
x86_64                              fedora-25

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From s.gottschall at dd-wrt.com  Thu Jul 23 19:06:23 2020
From: s.gottschall at dd-wrt.com (Sebastian Gottschall)
Date: Fri, 24 Jul 2020 01:06:23 +0200
Subject: [RFC 7/7] ath10k: Handle rx thread suspend and resume
In-Reply-To: <1595351666-28193-8-git-send-email-pillair@codeaurora.org>
References: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
 <1595351666-28193-8-git-send-email-pillair@codeaurora.org>
Message-ID: <1540605b-c54e-d482-296f-8139eb07c195@dd-wrt.com>

your patch seem to only affect the WCN3990 chipset. all other ath10k 
supported chipset are not supported here. so you see a chance to 
implement this more generic?

Sebastian

Am 21.07.2020 um 19:14 schrieb Rakesh Pillai:
> During the system suspend or resume, the rx thread
> also needs to be suspended or resume respectively.
>
> Handle the rx thread as well during the system
> suspend and resume.
>
> Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.1-01040-QCAHLSWMTPLZ-1
>
> Signed-off-by: Rakesh Pillai <pillair at codeaurora.org>
> ---
>   drivers/net/wireless/ath/ath10k/core.c | 23 ++++++++++++++++++
>   drivers/net/wireless/ath/ath10k/core.h |  5 ++++
>   drivers/net/wireless/ath/ath10k/snoc.c | 44 +++++++++++++++++++++++++++++++++-
>   3 files changed, 71 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
> index 4064fa2..b82b355 100644
> --- a/drivers/net/wireless/ath/ath10k/core.c
> +++ b/drivers/net/wireless/ath/ath10k/core.c
> @@ -668,6 +668,27 @@ static unsigned int ath10k_core_get_fw_feature_str(char *buf,
>   	return scnprintf(buf, buf_len, "%s", ath10k_core_fw_feature_str[feat]);
>   }
>   
> +int ath10k_core_thread_suspend(struct ath10k_thread *thread)
> +{
> +	ath10k_dbg(thread->ar, ATH10K_DBG_BOOT, "Suspending thread %s\n",
> +		   thread->name);
> +	set_bit(ATH10K_THREAD_EVENT_SUSPEND, thread->event_flags);
> +	wait_for_completion(&thread->suspend);
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL(ath10k_core_thread_suspend);
> +
> +int ath10k_core_thread_resume(struct ath10k_thread *thread)
> +{
> +	ath10k_dbg(thread->ar, ATH10K_DBG_BOOT, "Resuming thread %s\n",
> +		   thread->name);
> +	complete(&thread->resume);
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL(ath10k_core_thread_resume);
> +
>   void ath10k_core_thread_post_event(struct ath10k_thread *thread,
>   				   enum ath10k_thread_events event)
>   {
> @@ -700,6 +721,8 @@ int ath10k_core_thread_init(struct ath10k *ar,
>   
>   	init_waitqueue_head(&thread->wait_q);
>   	init_completion(&thread->shutdown);
> +	init_completion(&thread->suspend);
> +	init_completion(&thread->resume);
>   	memcpy(thread->name, thread_name, ATH10K_THREAD_NAME_SIZE_MAX);
>   	clear_bit(ATH10K_THREAD_EVENT_SHUTDOWN, thread->event_flags);
>   	ath10k_info(ar, "Starting thread %s\n", thread_name);
> diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
> index 596d31b..df65e75 100644
> --- a/drivers/net/wireless/ath/ath10k/core.h
> +++ b/drivers/net/wireless/ath/ath10k/core.h
> @@ -976,6 +976,7 @@ enum ath10k_thread_events {
>   	ATH10K_THREAD_EVENT_SHUTDOWN,
>   	ATH10K_THREAD_EVENT_RX_POST,
>   	ATH10K_THREAD_EVENT_TX_POST,
> +	ATH10K_THREAD_EVENT_SUSPEND,
>   	ATH10K_THREAD_EVENT_MAX,
>   };
>   
> @@ -983,6 +984,8 @@ struct ath10k_thread {
>   	struct ath10k *ar;
>   	struct task_struct *task;
>   	struct completion shutdown;
> +	struct completion suspend;
> +	struct completion resume;
>   	wait_queue_head_t wait_q;
>   	DECLARE_BITMAP(event_flags, ATH10K_THREAD_EVENT_MAX);
>   	char name[ATH10K_THREAD_NAME_SIZE_MAX];
> @@ -1296,6 +1299,8 @@ static inline bool ath10k_peer_stats_enabled(struct ath10k *ar)
>   
>   extern unsigned long ath10k_coredump_mask;
>   
> +int ath10k_core_thread_suspend(struct ath10k_thread *thread);
> +int ath10k_core_thread_resume(struct ath10k_thread *thread);
>   void ath10k_core_thread_post_event(struct ath10k_thread *thread,
>   				   enum ath10k_thread_events event);
>   int ath10k_core_thread_shutdown(struct ath10k *ar,
> diff --git a/drivers/net/wireless/ath/ath10k/snoc.c b/drivers/net/wireless/ath/ath10k/snoc.c
> index 3eb5eac..a373b2b 100644
> --- a/drivers/net/wireless/ath/ath10k/snoc.c
> +++ b/drivers/net/wireless/ath/ath10k/snoc.c
> @@ -932,13 +932,31 @@ int ath10k_snoc_rx_thread_loop(void *data)
>   					    rx_thread->event_flags) ||
>   			 test_and_clear_bit(ATH10K_THREAD_EVENT_TX_POST,
>   					    rx_thread->event_flags) ||
> +			 test_bit(ATH10K_THREAD_EVENT_SUSPEND,
> +				  rx_thread->event_flags) ||
>   			 test_bit(ATH10K_THREAD_EVENT_SHUTDOWN,
>   				  rx_thread->event_flags)));
>   
> +		if (test_and_clear_bit(ATH10K_THREAD_EVENT_SUSPEND,
> +				       rx_thread->event_flags)) {
> +			complete(&rx_thread->suspend);
> +			ath10k_info(ar, "rx thread suspend\n");
> +			wait_for_completion(&rx_thread->resume);
> +			ath10k_info(ar, "rx thread resume\n");
> +		}
> +
>   		ath10k_htt_txrx_compl_task(ar, thread_budget);
>   		if (test_and_clear_bit(ATH10K_THREAD_EVENT_SHUTDOWN,
>   				       rx_thread->event_flags))
>   			shutdown = true;
> +
> +		if (test_and_clear_bit(ATH10K_THREAD_EVENT_SUSPEND,
> +				       rx_thread->event_flags)) {
> +			complete(&rx_thread->suspend);
> +			ath10k_info(ar, "rx thread suspend\n");
> +			wait_for_completion(&rx_thread->resume);
> +			ath10k_info(ar, "rx thread resume\n");
> +		}
>   	}
>   
>   	ath10k_dbg(ar, ATH10K_DBG_SNOC, "rx thread exiting\n");
> @@ -1133,15 +1151,30 @@ static int ath10k_snoc_hif_suspend(struct ath10k *ar)
>   	if (!device_may_wakeup(ar->dev))
>   		return -EPERM;
>   
> +	if (ar->rx_thread_enable) {
> +		ret = ath10k_core_thread_suspend(&ar->rx_thread);
> +		if (ret) {
> +			ath10k_err(ar, "failed to suspend rx_thread, %d\n",
> +				   ret);
> +			return ret;
> +		}
> +	}
> +
>   	ret = enable_irq_wake(ar_snoc->ce_irqs[ATH10K_SNOC_WAKE_IRQ].irq_line);
>   	if (ret) {
>   		ath10k_err(ar, "failed to enable wakeup irq :%d\n", ret);
> -		return ret;
> +		goto fail;
>   	}
>   
>   	ath10k_dbg(ar, ATH10K_DBG_SNOC, "snoc device suspended\n");
>   
>   	return ret;
> +
> +fail:
> +	if (ar->rx_thread_enable)
> +		ath10k_core_thread_resume(&ar->rx_thread);
> +
> +	return ret;
>   }
>   
>   static int ath10k_snoc_hif_resume(struct ath10k *ar)
> @@ -1158,6 +1191,15 @@ static int ath10k_snoc_hif_resume(struct ath10k *ar)
>   		return ret;
>   	}
>   
> +	if (ar->rx_thread_enable) {
> +		ret = ath10k_core_thread_resume(&ar->rx_thread);
> +		if (ret) {
> +			ath10k_err(ar, "failed to suspend rx_thread, %d\n",
> +				   ret);
> +			return ret;
> +		}
> +	}
> +
>   	ath10k_dbg(ar, ATH10K_DBG_SNOC, "snoc device resumed\n");
>   
>   	return ret;


From pillair at codeaurora.org  Fri Jul 24 02:19:46 2020
From: pillair at codeaurora.org (Rakesh Pillai)
Date: Fri, 24 Jul 2020 11:49:46 +0530
Subject: [RFC 7/7] ath10k: Handle rx thread suspend and resume
In-Reply-To: <1540605b-c54e-d482-296f-8139eb07c195@dd-wrt.com>
References: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
 <1595351666-28193-8-git-send-email-pillair@codeaurora.org>
 <1540605b-c54e-d482-296f-8139eb07c195@dd-wrt.com>
Message-ID: <000001d66182$70d2bc30$52783490$@codeaurora.org>



> -----Original Message-----
> From: Sebastian Gottschall <s.gottschall at dd-wrt.com>
> Sent: Friday, July 24, 2020 4:36 AM
> To: Rakesh Pillai <pillair at codeaurora.org>; ath10k at lists.infradead.org
> Cc: linux-wireless at vger.kernel.org; linux-kernel at vger.kernel.org;
> kvalo at codeaurora.org; johannes at sipsolutions.net; davem at davemloft.net;
> kuba at kernel.org; netdev at vger.kernel.org; dianders at chromium.org;
> evgreen at chromium.org
> Subject: Re: [RFC 7/7] ath10k: Handle rx thread suspend and resume
> 
> your patch seem to only affect the WCN3990 chipset. all other ath10k
> supported chipset are not supported here. so you see a chance to
> implement this more generic?
> 
> Sebastian

Hi Sebastian,

A generic core for handling threads is added with this patchset.
So the handling of rx packet processing in thread can always be extended to other targets, if they wish so.

The thread related APIs are in core.c which gives all the other targets access to these APIs for using them.

Thanks,
Rakesh Pillai.

> 
> Am 21.07.2020 um 19:14 schrieb Rakesh Pillai:
> > During the system suspend or resume, the rx thread
> > also needs to be suspended or resume respectively.
> >
> > Handle the rx thread as well during the system
> > suspend and resume.
> >
> > Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.1-01040-QCAHLSWMTPLZ-1
> >
> > Signed-off-by: Rakesh Pillai <pillair at codeaurora.org>
> > ---
> >   drivers/net/wireless/ath/ath10k/core.c | 23 ++++++++++++++++++
> >   drivers/net/wireless/ath/ath10k/core.h |  5 ++++
> >   drivers/net/wireless/ath/ath10k/snoc.c | 44
> +++++++++++++++++++++++++++++++++-
> >   3 files changed, 71 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/wireless/ath/ath10k/core.c
> b/drivers/net/wireless/ath/ath10k/core.c
> > index 4064fa2..b82b355 100644
> > --- a/drivers/net/wireless/ath/ath10k/core.c
> > +++ b/drivers/net/wireless/ath/ath10k/core.c
> > @@ -668,6 +668,27 @@ static unsigned int
> ath10k_core_get_fw_feature_str(char *buf,
> >   	return scnprintf(buf, buf_len, "%s",
> ath10k_core_fw_feature_str[feat]);
> >   }
> >
> > +int ath10k_core_thread_suspend(struct ath10k_thread *thread)
> > +{
> > +	ath10k_dbg(thread->ar, ATH10K_DBG_BOOT, "Suspending thread
> %s\n",
> > +		   thread->name);
> > +	set_bit(ATH10K_THREAD_EVENT_SUSPEND, thread->event_flags);
> > +	wait_for_completion(&thread->suspend);
> > +
> > +	return 0;
> > +}
> > +EXPORT_SYMBOL(ath10k_core_thread_suspend);
> > +
> > +int ath10k_core_thread_resume(struct ath10k_thread *thread)
> > +{
> > +	ath10k_dbg(thread->ar, ATH10K_DBG_BOOT, "Resuming thread
> %s\n",
> > +		   thread->name);
> > +	complete(&thread->resume);
> > +
> > +	return 0;
> > +}
> > +EXPORT_SYMBOL(ath10k_core_thread_resume);
> > +
> >   void ath10k_core_thread_post_event(struct ath10k_thread *thread,
> >   				   enum ath10k_thread_events event)
> >   {
> > @@ -700,6 +721,8 @@ int ath10k_core_thread_init(struct ath10k *ar,
> >
> >   	init_waitqueue_head(&thread->wait_q);
> >   	init_completion(&thread->shutdown);
> > +	init_completion(&thread->suspend);
> > +	init_completion(&thread->resume);
> >   	memcpy(thread->name, thread_name,
> ATH10K_THREAD_NAME_SIZE_MAX);
> >   	clear_bit(ATH10K_THREAD_EVENT_SHUTDOWN, thread-
> >event_flags);
> >   	ath10k_info(ar, "Starting thread %s\n", thread_name);
> > diff --git a/drivers/net/wireless/ath/ath10k/core.h
> b/drivers/net/wireless/ath/ath10k/core.h
> > index 596d31b..df65e75 100644
> > --- a/drivers/net/wireless/ath/ath10k/core.h
> > +++ b/drivers/net/wireless/ath/ath10k/core.h
> > @@ -976,6 +976,7 @@ enum ath10k_thread_events {
> >   	ATH10K_THREAD_EVENT_SHUTDOWN,
> >   	ATH10K_THREAD_EVENT_RX_POST,
> >   	ATH10K_THREAD_EVENT_TX_POST,
> > +	ATH10K_THREAD_EVENT_SUSPEND,
> >   	ATH10K_THREAD_EVENT_MAX,
> >   };
> >
> > @@ -983,6 +984,8 @@ struct ath10k_thread {
> >   	struct ath10k *ar;
> >   	struct task_struct *task;
> >   	struct completion shutdown;
> > +	struct completion suspend;
> > +	struct completion resume;
> >   	wait_queue_head_t wait_q;
> >   	DECLARE_BITMAP(event_flags, ATH10K_THREAD_EVENT_MAX);
> >   	char name[ATH10K_THREAD_NAME_SIZE_MAX];
> > @@ -1296,6 +1299,8 @@ static inline bool
> ath10k_peer_stats_enabled(struct ath10k *ar)
> >
> >   extern unsigned long ath10k_coredump_mask;
> >
> > +int ath10k_core_thread_suspend(struct ath10k_thread *thread);
> > +int ath10k_core_thread_resume(struct ath10k_thread *thread);
> >   void ath10k_core_thread_post_event(struct ath10k_thread *thread,
> >   				   enum ath10k_thread_events event);
> >   int ath10k_core_thread_shutdown(struct ath10k *ar,
> > diff --git a/drivers/net/wireless/ath/ath10k/snoc.c
> b/drivers/net/wireless/ath/ath10k/snoc.c
> > index 3eb5eac..a373b2b 100644
> > --- a/drivers/net/wireless/ath/ath10k/snoc.c
> > +++ b/drivers/net/wireless/ath/ath10k/snoc.c
> > @@ -932,13 +932,31 @@ int ath10k_snoc_rx_thread_loop(void *data)
> >   					    rx_thread->event_flags) ||
> >
> test_and_clear_bit(ATH10K_THREAD_EVENT_TX_POST,
> >   					    rx_thread->event_flags) ||
> > +			 test_bit(ATH10K_THREAD_EVENT_SUSPEND,
> > +				  rx_thread->event_flags) ||
> >   			 test_bit(ATH10K_THREAD_EVENT_SHUTDOWN,
> >   				  rx_thread->event_flags)));
> >
> > +		if (test_and_clear_bit(ATH10K_THREAD_EVENT_SUSPEND,
> > +				       rx_thread->event_flags)) {
> > +			complete(&rx_thread->suspend);
> > +			ath10k_info(ar, "rx thread suspend\n");
> > +			wait_for_completion(&rx_thread->resume);
> > +			ath10k_info(ar, "rx thread resume\n");
> > +		}
> > +
> >   		ath10k_htt_txrx_compl_task(ar, thread_budget);
> >   		if
> (test_and_clear_bit(ATH10K_THREAD_EVENT_SHUTDOWN,
> >   				       rx_thread->event_flags))
> >   			shutdown = true;
> > +
> > +		if (test_and_clear_bit(ATH10K_THREAD_EVENT_SUSPEND,
> > +				       rx_thread->event_flags)) {
> > +			complete(&rx_thread->suspend);
> > +			ath10k_info(ar, "rx thread suspend\n");
> > +			wait_for_completion(&rx_thread->resume);
> > +			ath10k_info(ar, "rx thread resume\n");
> > +		}
> >   	}
> >
> >   	ath10k_dbg(ar, ATH10K_DBG_SNOC, "rx thread exiting\n");
> > @@ -1133,15 +1151,30 @@ static int ath10k_snoc_hif_suspend(struct
> ath10k *ar)
> >   	if (!device_may_wakeup(ar->dev))
> >   		return -EPERM;
> >
> > +	if (ar->rx_thread_enable) {
> > +		ret = ath10k_core_thread_suspend(&ar->rx_thread);
> > +		if (ret) {
> > +			ath10k_err(ar, "failed to suspend rx_thread, %d\n",
> > +				   ret);
> > +			return ret;
> > +		}
> > +	}
> > +
> >   	ret = enable_irq_wake(ar_snoc-
> >ce_irqs[ATH10K_SNOC_WAKE_IRQ].irq_line);
> >   	if (ret) {
> >   		ath10k_err(ar, "failed to enable wakeup irq :%d\n", ret);
> > -		return ret;
> > +		goto fail;
> >   	}
> >
> >   	ath10k_dbg(ar, ATH10K_DBG_SNOC, "snoc device suspended\n");
> >
> >   	return ret;
> > +
> > +fail:
> > +	if (ar->rx_thread_enable)
> > +		ath10k_core_thread_resume(&ar->rx_thread);
> > +
> > +	return ret;
> >   }
> >
> >   static int ath10k_snoc_hif_resume(struct ath10k *ar)
> > @@ -1158,6 +1191,15 @@ static int ath10k_snoc_hif_resume(struct ath10k
> *ar)
> >   		return ret;
> >   	}
> >
> > +	if (ar->rx_thread_enable) {
> > +		ret = ath10k_core_thread_resume(&ar->rx_thread);
> > +		if (ret) {
> > +			ath10k_err(ar, "failed to suspend rx_thread, %d\n",
> > +				   ret);
> > +			return ret;
> > +		}
> > +	}
> > +
> >   	ath10k_dbg(ar, ATH10K_DBG_SNOC, "snoc device resumed\n");
> >
> >   	return ret;



From pillair at codeaurora.org  Fri Jul 24 02:20:27 2020
From: pillair at codeaurora.org (Rakesh Pillai)
Date: Fri, 24 Jul 2020 11:50:27 +0530
Subject: [RFC 0/7] Add support to process rx packets in thread
In-Reply-To: <fdedf787-1bb0-601c-0959-6f1bfb38e5d7@gmail.com>
References: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
 <20200721172514.GT1339445@lunn.ch>
 <f6d93d76-9e59-c257-9318-31c71df28018@gmail.com>
 <002e01d6611e$0d8ac640$28a052c0$@codeaurora.org>
 <fdedf787-1bb0-601c-0959-6f1bfb38e5d7@gmail.com>
Message-ID: <000201d66182$8989a3b0$9c9ceb10$@codeaurora.org>



> -----Original Message-----
> From: Florian Fainelli <f.fainelli at gmail.com>
> Sent: Friday, July 24, 2020 12:33 AM
> To: Rakesh Pillai <pillair at codeaurora.org>; 'Andrew Lunn'
> <andrew at lunn.ch>
> Cc: ath10k at lists.infradead.org; linux-wireless at vger.kernel.org; linux-
> kernel at vger.kernel.org; kvalo at codeaurora.org; johannes at sipsolutions.net;
> davem at davemloft.net; kuba at kernel.org; netdev at vger.kernel.org;
> dianders at chromium.org; evgreen at chromium.org
> Subject: Re: [RFC 0/7] Add support to process rx packets in thread
> 
> On 7/23/20 11:21 AM, Rakesh Pillai wrote:
> >
> >
> >> -----Original Message-----
> >> From: Florian Fainelli <f.fainelli at gmail.com>
> >> Sent: Tuesday, July 21, 2020 11:35 PM
> >> To: Andrew Lunn <andrew at lunn.ch>; Rakesh Pillai
> <pillair at codeaurora.org>
> >> Cc: ath10k at lists.infradead.org; linux-wireless at vger.kernel.org; linux-
> >> kernel at vger.kernel.org; kvalo at codeaurora.org;
> johannes at sipsolutions.net;
> >> davem at davemloft.net; kuba at kernel.org; netdev at vger.kernel.org;
> >> dianders at chromium.org; evgreen at chromium.org
> >> Subject: Re: [RFC 0/7] Add support to process rx packets in thread
> >>
> >> On 7/21/20 10:25 AM, Andrew Lunn wrote:
> >>> On Tue, Jul 21, 2020 at 10:44:19PM +0530, Rakesh Pillai wrote:
> >>>> NAPI gets scheduled on the CPU core which got the
> >>>> interrupt. The linux scheduler cannot move it to a
> >>>> different core, even if the CPU on which NAPI is running
> >>>> is heavily loaded. This can lead to degraded wifi
> >>>> performance when running traffic at peak data rates.
> >>>>
> >>>> A thread on the other hand can be moved to different
> >>>> CPU cores, if the one on which its running is heavily
> >>>> loaded. During high incoming data traffic, this gives
> >>>> better performance, since the thread can be moved to a
> >>>> less loaded or sometimes even a more powerful CPU core
> >>>> to account for the required CPU performance in order
> >>>> to process the incoming packets.
> >>>>
> >>>> This patch series adds the support to use a high priority
> >>>> thread to process the incoming packets, as opposed to
> >>>> everything being done in NAPI context.
> >>>
> >>> I don't see why this problem is limited to the ath10k driver. I expect
> >>> it applies to all drivers using NAPI. So shouldn't you be solving this
> >>> in the NAPI core? Allow a driver to request the NAPI core uses a
> >>> thread?
> >>
> >> What's more, you should be able to configure interrupt affinity to steer
> >> RX processing onto a desired CPU core, is not that working for you
> >> somehow?
> >
> > Hi Florian,
> > Yes, the affinity of IRQ does work for me.
> > But the affinity of IRQ does not happen runtime based on load.
> 
> It can if you also run irqbalance.


Hi Florian,

Is it some kernel feature ?  Sorry I am not aware of this ?
I know it can be done in userspace.

> --
> Florian



From pillair at codeaurora.org  Fri Jul 24 02:21:12 2020
From: pillair at codeaurora.org (Rakesh Pillai)
Date: Fri, 24 Jul 2020 11:51:12 +0530
Subject: [RFC 1/7] mac80211: Add check for napi handle before WARN_ON
In-Reply-To: <ce380ea1fd1f5db40a92f67673f070a1f88eee50.camel@sipsolutions.net>
References: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>		
 <1595351666-28193-2-git-send-email-pillair@codeaurora.org>	
 <0dbdef912f9d61521011f638200fd451a3530568.camel@sipsolutions.net>	
 <003201d6611e$c54a1c90$4fde55b0$@codeaurora.org>
 <ce380ea1fd1f5db40a92f67673f070a1f88eee50.camel@sipsolutions.net>
Message-ID: <000401d66182$a3d97ab0$eb8c7010$@codeaurora.org>



> -----Original Message-----
> From: Johannes Berg <johannes at sipsolutions.net>
> Sent: Friday, July 24, 2020 1:37 AM
> To: Rakesh Pillai <pillair at codeaurora.org>; ath10k at lists.infradead.org
> Cc: linux-wireless at vger.kernel.org; linux-kernel at vger.kernel.org;
> kvalo at codeaurora.org; davem at davemloft.net; kuba at kernel.org;
> netdev at vger.kernel.org; dianders at chromium.org; evgreen at chromium.org
> Subject: Re: [RFC 1/7] mac80211: Add check for napi handle before
> WARN_ON
> 
> On Thu, 2020-07-23 at 23:56 +0530, Rakesh Pillai wrote:
> 
> > > > -	WARN_ON_ONCE(softirq_count() == 0);
> > > > +	WARN_ON_ONCE(napi && softirq_count() == 0);
> > >
> > > FWIW, I'm pretty sure this is incorrect - we make assumptions on
> > > softirqs being disabled in mac80211 for serialization and in place of
> > > some locking, I believe.
> > >
> >
> > I checked this, but let me double confirm.
> > But after this change, no packet is submitted from driver in a softirq
> context.
> > So ideally this should take care of serialization.
> 
> I'd guess that we have some reliance on BHs already being disabled, for
> things like u64 sync updates, or whatnot. I mean, we did "rx_ni()" for a
> reason ... Maybe lockdep can help catch some of the issues.
> 
> But couldn't you be in a thread and have BHs disabled too?

This would ideally beat the purpose and possibly hurt the other subsystems running on the same core.

> 
> johannes




From kvalo at codeaurora.org  Fri Jul 24 05:26:16 2020
From: kvalo at codeaurora.org (Kalle Valo)
Date: Fri, 24 Jul 2020 12:26:16 +0300
Subject: [PATCH 1/2] nl80211: vendor-cmd: qca: add dynamic SAR power limits
In-Reply-To: <CA+ASDXOAzPuOn_rMsRj4t56kC-TgoG0p5WhSTPJjB8xTTq5kfg@mail.gmail.com>
 (Brian Norris's message of "Thu, 16 Jul 2020 11:56:39 -0700")
References: <1576684108-30177-1-git-send-email-kvalo@codeaurora.org>
 <1576684108-30177-2-git-send-email-kvalo@codeaurora.org>
 <1576748692.7758.17.camel@realtek.com> <20191219154828.GA12287@w1.fi>
 <CA+ASDXMTYLGbEkBPHSqtyitMEvY5o_MjU0s+NoWdnN_ORy1gDw@mail.gmail.com>
 <20191219185522.GA16010@w1.fi>
 <CA+ASDXNOxkrZTxL0Jo4ONR2YtL83BVc_w-rBXc6ggBLdwUpDZw@mail.gmail.com>
 <871rpqly6a.fsf@kamboji.qca.qualcomm.com>
 <e8908eafd8e6050eef8782c6a7019e318d14f65f.camel@sipsolutions.net>
 <CA+ASDXMf7iXuE9hQ-XitPPfvXP0EK5FchJLCu2+5Ag=ZC=0H0w@mail.gmail.com>
 <87lfjjx0o7.fsf@codeaurora.org>
 <CA+ASDXOAzPuOn_rMsRj4t56kC-TgoG0p5WhSTPJjB8xTTq5kfg@mail.gmail.com>
Message-ID: <87y2n9clhj.fsf@codeaurora.org>

Brian Norris <briannorris at chromium.org> writes:

> On Thu, Jul 16, 2020 at 2:35 AM Kalle Valo <kvalo at codeaurora.org> wrote:
>> Brian Norris <briannorris at chromium.org> writes:
>> > Really, I could live with per-vendor APIs. My primary goal is to get
>> > these upstream in some form, so vendors can stop using things like
>> > this as a reason for shipping us non-upstream code, and so we can
>> > reduce the delta between upstream and Chrome OS kernels.
>> >
>> > I also think that, for the cases that warrant it (i.e., the option 2
>> > -- Realtek and Qualcomm cases, so far), it would be good to have a
>> > common API, but that's a somewhat secondary concern for me.
>>
>> So to me it feels like the best solution forward is to go with the
>> vendor API, do you agree? We can, of course, later switch to the common
>> API if we manage to create one which is usable for everyone.
>
> That's fine with me. That's pretty much what I said in my first email:
>
> "Anyway, I don't really object with starting out with a
> Qualcomm-specific and a Realtek-specific vendor command to implement
> nearly the same feature, but I'd prefer if people did engage in some
> healthy discussion about why they can't share an API, with the hopes
> that maybe they can converge someday."
>
> I think we've had some healthy (though very protracted) discussion,
> and I don't think I've seen anyone bring up anything I wasn't already
> aware of that would prevent eventual consolidation. As long as we
> acknowledge those things (item 2 at
> https://wireless.wiki.kernel.org/en/developers/documentation/nl80211#vendor-specific_api),
> I'm happy.

Good, I was just checking that we all are on the same page.

>> > Also, Kalle had some concerns about stable ABI questions: shouldn't we
>> > bake in some kind of "check for support" feature to these kinds of
>> > APIs [3]? That would help ease transition, if we do start with a
>> > vendor API and move to a common one in the future.
>>
>> Yeah, that sounds like a good idea but I don't think that should block
>> these patches.
>
> OK, well it was your concern first, IIRC :)

I was commenting about the "check for support" feature :) I think it
would be a good idea to have userspace check what vendor interface
features/commands are supported with that driver/hardware/firmware
combo. But how should that be implemented? Should there be a some kind
of generic mechanism used by all drivers or would each driver have their
own method to check the supported features? I think that needs a
separate discussion.

> So what's next? A v2 that only needs a bit of updated description
> about "why a vendor API"?

I'm busy but hopefully Wen (CCed) can submit v2. Wen?

> And Realtek can feel free to submit this [1] shortly?

> [1] Series: rtw88: Add SAR implementation
> https://patchwork.kernel.org/project/linux-wireless/list/?series=238219&state=*

Yeah, please submit that as well.

-- 
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


From lkp at intel.com  Fri Jul 24 10:54:54 2020
From: lkp at intel.com (kernel test robot)
Date: Fri, 24 Jul 2020 22:54:54 +0800
Subject: [ath6kl:ath11k-qca6390-bringup] BUILD SUCCESS
 e112cced2e828a81bf0f77dc5c136f9174b49ca4
Message-ID: <5f1af63e.vPuiB5uf5rUo+IRx%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git  ath11k-qca6390-bringup
branch HEAD: e112cced2e828a81bf0f77dc5c136f9174b49ca4  HACK: ath11k: disable L1 to prevent device entering low power state

elapsed time: 1094m

configs tested: 74
configs skipped: 1

The following configs have been built successfully.
More configs may be tested in the coming days.

arm                                 defconfig
arm                              allyesconfig
arm                              allmodconfig
arm                               allnoconfig
arm64                            allyesconfig
arm64                               defconfig
arm64                            allmodconfig
arm64                             allnoconfig
i386                             allyesconfig
i386                                defconfig
i386                              debian-10.3
i386                              allnoconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                              allnoconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                              allnoconfig
m68k                           sun3_defconfig
m68k                                defconfig
m68k                             allyesconfig
nds32                               defconfig
nds32                             allnoconfig
csky                             allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
h8300                            allmodconfig
xtensa                              defconfig
arc                                 defconfig
arc                              allyesconfig
sh                               allmodconfig
sh                                allnoconfig
microblaze                        allnoconfig
nios2                               defconfig
nios2                            allyesconfig
openrisc                            defconfig
c6x                              allyesconfig
c6x                               allnoconfig
openrisc                         allyesconfig
mips                             allyesconfig
mips                              allnoconfig
mips                             allmodconfig
parisc                            allnoconfig
parisc                              defconfig
parisc                           allyesconfig
parisc                           allmodconfig
powerpc                             defconfig
powerpc                          allyesconfig
powerpc                          rhel-kconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
riscv                            allyesconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                            allmodconfig
s390                             allyesconfig
s390                              allnoconfig
s390                             allmodconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
sparc64                             defconfig
sparc64                           allnoconfig
sparc64                          allyesconfig
sparc64                          allmodconfig
x86_64                    rhel-7.6-kselftests
x86_64                               rhel-8.3
x86_64                                  kexec
x86_64                                   rhel
x86_64                                    lkp
x86_64                              fedora-25

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From f.fainelli at gmail.com  Fri Jul 24 18:28:03 2020
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Fri, 24 Jul 2020 15:28:03 -0700
Subject: [RFC 0/7] Add support to process rx packets in thread
In-Reply-To: <000201d66182$8989a3b0$9c9ceb10$@codeaurora.org>
References: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
 <20200721172514.GT1339445@lunn.ch>
 <f6d93d76-9e59-c257-9318-31c71df28018@gmail.com>
 <002e01d6611e$0d8ac640$28a052c0$@codeaurora.org>
 <fdedf787-1bb0-601c-0959-6f1bfb38e5d7@gmail.com>
 <000201d66182$8989a3b0$9c9ceb10$@codeaurora.org>
Message-ID: <80490faa-f9e8-3bac-a645-7458b9d6aa62@gmail.com>

On 7/23/20 11:20 PM, Rakesh Pillai wrote:
> 
> 
>> -----Original Message-----
>> From: Florian Fainelli <f.fainelli at gmail.com>
>> Sent: Friday, July 24, 2020 12:33 AM
>> To: Rakesh Pillai <pillair at codeaurora.org>; 'Andrew Lunn'
>> <andrew at lunn.ch>
>> Cc: ath10k at lists.infradead.org; linux-wireless at vger.kernel.org; linux-
>> kernel at vger.kernel.org; kvalo at codeaurora.org; johannes at sipsolutions.net;
>> davem at davemloft.net; kuba at kernel.org; netdev at vger.kernel.org;
>> dianders at chromium.org; evgreen at chromium.org
>> Subject: Re: [RFC 0/7] Add support to process rx packets in thread
>>
>> On 7/23/20 11:21 AM, Rakesh Pillai wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Florian Fainelli <f.fainelli at gmail.com>
>>>> Sent: Tuesday, July 21, 2020 11:35 PM
>>>> To: Andrew Lunn <andrew at lunn.ch>; Rakesh Pillai
>> <pillair at codeaurora.org>
>>>> Cc: ath10k at lists.infradead.org; linux-wireless at vger.kernel.org; linux-
>>>> kernel at vger.kernel.org; kvalo at codeaurora.org;
>> johannes at sipsolutions.net;
>>>> davem at davemloft.net; kuba at kernel.org; netdev at vger.kernel.org;
>>>> dianders at chromium.org; evgreen at chromium.org
>>>> Subject: Re: [RFC 0/7] Add support to process rx packets in thread
>>>>
>>>> On 7/21/20 10:25 AM, Andrew Lunn wrote:
>>>>> On Tue, Jul 21, 2020 at 10:44:19PM +0530, Rakesh Pillai wrote:
>>>>>> NAPI gets scheduled on the CPU core which got the
>>>>>> interrupt. The linux scheduler cannot move it to a
>>>>>> different core, even if the CPU on which NAPI is running
>>>>>> is heavily loaded. This can lead to degraded wifi
>>>>>> performance when running traffic at peak data rates.
>>>>>>
>>>>>> A thread on the other hand can be moved to different
>>>>>> CPU cores, if the one on which its running is heavily
>>>>>> loaded. During high incoming data traffic, this gives
>>>>>> better performance, since the thread can be moved to a
>>>>>> less loaded or sometimes even a more powerful CPU core
>>>>>> to account for the required CPU performance in order
>>>>>> to process the incoming packets.
>>>>>>
>>>>>> This patch series adds the support to use a high priority
>>>>>> thread to process the incoming packets, as opposed to
>>>>>> everything being done in NAPI context.
>>>>>
>>>>> I don't see why this problem is limited to the ath10k driver. I expect
>>>>> it applies to all drivers using NAPI. So shouldn't you be solving this
>>>>> in the NAPI core? Allow a driver to request the NAPI core uses a
>>>>> thread?
>>>>
>>>> What's more, you should be able to configure interrupt affinity to steer
>>>> RX processing onto a desired CPU core, is not that working for you
>>>> somehow?
>>>
>>> Hi Florian,
>>> Yes, the affinity of IRQ does work for me.
>>> But the affinity of IRQ does not happen runtime based on load.
>>
>> It can if you also run irqbalance.
> 
> 
> Hi Florian,
> 
> Is it some kernel feature ?  Sorry I am not aware of this ?
> I know it can be done in userspace.

The kernel interface is /proc/<irq>/smp_affinity and the users-space
implementation resides here:

https://github.com/Irqbalance/irqbalance
-- 
Florian


From jacob.e.keller at intel.com  Fri Jul 24 19:11:57 2020
From: jacob.e.keller at intel.com (Jacob Keller)
Date: Fri, 24 Jul 2020 16:11:57 -0700
Subject: [RFC 2/7] ath10k: Add support to process rx packet in thread
In-Reply-To: <003001d6611e$9afa0cc0$d0ee2640$@codeaurora.org>
References: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
 <1595351666-28193-3-git-send-email-pillair@codeaurora.org>
 <13573549c277b34d4c87c471ff1a7060@codeaurora.org>
 <003001d6611e$9afa0cc0$d0ee2640$@codeaurora.org>
Message-ID: <0d9baad4-fba7-d362-41b7-f0b37446c5ef@intel.com>



On 7/23/2020 11:25 AM, Rakesh Pillai wrote:
> Hi Rajkumar,
> In linux, the IRQs are directed to the first core which is booted.
> I see that all the IRQs are getting routed to CORE0 even if its heavily
> loaded.
> 

You should be able to configure the initial IRQ setup so that they don't
all go on CPU 0 when you create the IRQ. That obviously doesn't help the
case of wanting scheduler to dynamically move the processing around to
other CPUs though.


From hdanton at sina.com  Sat Jul 25 04:16:33 2020
From: hdanton at sina.com (Hillf Danton)
Date: Sat, 25 Jul 2020 16:16:33 +0800
Subject: [RFC 0/7] Add support to process rx packets in thread
In-Reply-To: <9fb3d3bd8d944a649cbe828fddca1bc1@AcuMS.aculab.com>
References: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
 <20200721172514.GT1339445@lunn.ch>
Message-ID: <20200725081633.7432-1-hdanton@sina.com>


On Wed, 22 Jul 2020 09:12:42 +0000 David Laight wrote:
> > On 21 July 2020 18:25 Andrew Lunn wrote:
> > 
> > On Tue, Jul 21, 2020 at 10:44:19PM +0530, Rakesh Pillai wrote:
> > > NAPI gets scheduled on the CPU core which got the
> > > interrupt. The linux scheduler cannot move it to a
> > > different core, even if the CPU on which NAPI is running
> > > is heavily loaded. This can lead to degraded wifi
> > > performance when running traffic at peak data rates.
> > >
> > > A thread on the other hand can be moved to different
> > > CPU cores, if the one on which its running is heavily
> > > loaded. During high incoming data traffic, this gives
> > > better performance, since the thread can be moved to a
> > > less loaded or sometimes even a more powerful CPU core
> > > to account for the required CPU performance in order
> > > to process the incoming packets.
> > >
> > > This patch series adds the support to use a high priority
> > > thread to process the incoming packets, as opposed to
> > > everything being done in NAPI context.
> > 
> > I don't see why this problem is limited to the ath10k driver. I expect
> > it applies to all drivers using NAPI. So shouldn't you be solving this
> > in the NAPI core? Allow a driver to request the NAPI core uses a
> > thread?
> 
> It's not just NAPI the problem is with the softint processing.
> I suspect a lot of systems would work better if it ran as
> a (highish priority) kernel thread.

Hi folks

Below is a minimunm poc implementation I can imagine on top of workqueue
to make napi threaded. Thoughts are appreciated.

> I've had to remove the main locks from a multi-threaded application
> and replace them with atomic counters.
> Consider what happens when the threads remove items from a shared
> work list.
> The code looks like:
> 	mutex_enter();
> 	remove_item_from_list();
> 	mutex_exit().
> The mutex is only held for a few instructions, so while you'd expect
> the cache line to be 'hot' you wouldn't get real contention.
> However the following scenarios happen:
> 1) An ethernet interrupt happens while the mutex is held.
>    This stops the other threads until all the softint processing
>    has finished.
> 2) An ethernet interrupt (and softint) runs on a thread that is
>    waiting for the mutex.
>    (Or on the cpu that the thread's processor affinity ties it to.)
>    In this case the 'fair' (ticket) mutex code won't let any other
>    thread acquire the mutex.
>    So again everything stops until the softints all complete.
> 
> The second one is also a problem when trying to wake up all
> the threads (eg after adding a lot of items to the list).
> The ticket locks force them to wake in order, but
> sometimes the 'thundering herd' would work better.
> 
> IIRC this is actually worse for processes running under the RT
> scheduler (without CONFIG_PREEMPT) because the they are almost
> always scheduled on the same cpu they ran on last.
> If it is busy, but cannot be pre-empted, they are not moved
> to an idle cpu.
>    
> To confound things there is a very broken workaround for broken
> hardware in the driver for the e1000 interface on (at least)
> Ivy Bridge cpu that can cause the driver to spin for a very
> long time (IIRC milliseconds) whenever it has to write to a
> MAC register (ie on every transmit setup).
> 
> 	David
> 
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)

To make napi threaded, if either irq or softirq thread is entirely ruled
out, add napi::work that will be queued on a highpri workqueue. It is
actually a unbound one to facilitate scheduler to catter napi loads on to
idle CPU cores. What users need to do with the threaded napi
is s/netif_napi_add/netif_threaded_napi_add/ and no more.

--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -338,6 +338,9 @@ struct napi_struct {
 	struct list_head	dev_list;
 	struct hlist_node	napi_hash_node;
 	unsigned int		napi_id;
+#ifdef CONFIG_THREADED_NAPI
+	struct work_struct	work;
+#endif
 };
 
 enum {
@@ -2234,6 +2237,19 @@ static inline void *netdev_priv(const st
 void netif_napi_add(struct net_device *dev, struct napi_struct *napi,
 		    int (*poll)(struct napi_struct *, int), int weight);
 
+#ifdef CONFIG_THREADED_NAPI
+void netif_threaded_napi_add(struct net_device *dev, struct napi_struct *napi,
+		    int (*poll)(struct napi_struct *, int), int weight);
+#else
+static inline void netif_threaded_napi_add(struct net_device *dev,
+					struct napi_struct *napi,
+					int (*poll)(struct napi_struct *, int),
+					int weight)
+{
+	netif_napi_add(dev, napi, poll, weight);
+}
+#endif
+
 /**
  *	netif_tx_napi_add - initialize a NAPI context
  *	@dev:  network device
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -6277,6 +6277,61 @@ static int process_backlog(struct napi_s
 	return work;
 }
 
+#ifdef CONFIG_THREADED_NAPI
+/* unbound highpri workqueue for threaded napi */
+static struct workqueue_struct *napi_workq;
+
+static void napi_workfn(struct work_struct *work)
+{
+	struct napi_struct *n = container_of(work, struct napi_struct, work);
+
+	for (;;) {
+		if (!test_bit(NAPI_STATE_SCHED, &n->state))
+			return;
+
+		if (n->poll(n, n->weight) < n->weight)
+			return;
+
+		if (need_resched()) {
+			/*
+			 * have to pay for the latency of task switch even if 
+			 * napi is scheduled
+			 */
+			if (test_bit(NAPI_STATE_SCHED, &n->state))
+				queue_work(napi_workq, work);
+			return;
+		}
+	}
+}
+
+void netif_threaded_napi_add(struct net_device *dev,
+				struct napi_struct *napi,
+				int (*poll)(struct napi_struct *, int),
+				int weight)
+{
+	netif_napi_add(dev, napi, poll, weight);
+	INIT_WORK(&napi->work, napi_workfn);
+}
+
+static inline bool is_threaded_napi(struct napi_struct *n)
+{
+	return n->work.func == napi_workfn;
+}
+
+static inline void threaded_napi_sched(struct napi_struct *n)
+{
+	if (is_threaded_napi(n))
+		queue_work(napi_workq, &n->work);
+	else
+		____napi_schedule(this_cpu_ptr(&softnet_data), n);
+}
+#else
+static inline void threaded_napi_sched(struct napi_struct *n)
+{
+	____napi_schedule(this_cpu_ptr(&softnet_data), n);
+}
+#endif
+
 /**
  * __napi_schedule - schedule for receive
  * @n: entry to schedule
@@ -6289,7 +6344,7 @@ void __napi_schedule(struct napi_struct
 	unsigned long flags;
 
 	local_irq_save(flags);
-	____napi_schedule(this_cpu_ptr(&softnet_data), n);
+	threaded_napi_sched(n);
 	local_irq_restore(flags);
 }
 EXPORT_SYMBOL(__napi_schedule);
@@ -6335,7 +6390,7 @@ EXPORT_SYMBOL(napi_schedule_prep);
  */
 void __napi_schedule_irqoff(struct napi_struct *n)
 {
-	____napi_schedule(this_cpu_ptr(&softnet_data), n);
+	threaded_napi_sched(n);
 }
 EXPORT_SYMBOL(__napi_schedule_irqoff);
 
@@ -10685,6 +10740,10 @@ static int __init net_dev_init(void)
 		sd->backlog.weight = weight_p;
 	}
 
+#ifdef CONFIG_THREADED_NAPI
+	napi_workq = alloc_workqueue("napi_workq", WQ_UNBOUND | WQ_HIGHPRI,
+					    WQ_UNBOUND_MAX_ACTIVE);
+#endif
 	dev_boot_phase = 0;
 
 	/* The loopback device is special if any other network devices



From s.gottschall at dd-wrt.com  Sat Jul 25 06:38:00 2020
From: s.gottschall at dd-wrt.com (Sebastian Gottschall)
Date: Sat, 25 Jul 2020 12:38:00 +0200
Subject: [RFC 0/7] Add support to process rx packets in thread
In-Reply-To: <20200725081633.7432-1-hdanton@sina.com>
References: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
 <20200721172514.GT1339445@lunn.ch> <20200725081633.7432-1-hdanton@sina.com>
Message-ID: <8359a849-2b8a-c842-a501-c6cb6966e345@dd-wrt.com>

you may consider this

https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1142611.html 
<https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1142611.html>

years ago someone already wanted to bring this feature upstream, but it 
was denied. i already tested this patch the last 2 days and it worked so 
far (with some little modifications)
so such a solution existed already and may be considered here

Sebastian


someone

Am 25.07.2020 um 10:16 schrieb Hillf Danton:
> On Wed, 22 Jul 2020 09:12:42 +0000 David Laight wrote:
>>> On 21 July 2020 18:25 Andrew Lunn wrote:
>>>
>>> On Tue, Jul 21, 2020 at 10:44:19PM +0530, Rakesh Pillai wrote:
>>>> NAPI gets scheduled on the CPU core which got the
>>>> interrupt. The linux scheduler cannot move it to a
>>>> different core, even if the CPU on which NAPI is running
>>>> is heavily loaded. This can lead to degraded wifi
>>>> performance when running traffic at peak data rates.
>>>>
>>>> A thread on the other hand can be moved to different
>>>> CPU cores, if the one on which its running is heavily
>>>> loaded. During high incoming data traffic, this gives
>>>> better performance, since the thread can be moved to a
>>>> less loaded or sometimes even a more powerful CPU core
>>>> to account for the required CPU performance in order
>>>> to process the incoming packets.
>>>>
>>>> This patch series adds the support to use a high priority
>>>> thread to process the incoming packets, as opposed to
>>>> everything being done in NAPI context.
>>> I don't see why this problem is limited to the ath10k driver. I expect
>>> it applies to all drivers using NAPI. So shouldn't you be solving this
>>> in the NAPI core? Allow a driver to request the NAPI core uses a
>>> thread?
>> It's not just NAPI the problem is with the softint processing.
>> I suspect a lot of systems would work better if it ran as
>> a (highish priority) kernel thread.
> Hi folks
>
> Below is a minimunm poc implementation I can imagine on top of workqueue
> to make napi threaded. Thoughts are appreciated.
>
>> I've had to remove the main locks from a multi-threaded application
>> and replace them with atomic counters.
>> Consider what happens when the threads remove items from a shared
>> work list.
>> The code looks like:
>> 	mutex_enter();
>> 	remove_item_from_list();
>> 	mutex_exit().
>> The mutex is only held for a few instructions, so while you'd expect
>> the cache line to be 'hot' you wouldn't get real contention.
>> However the following scenarios happen:
>> 1) An ethernet interrupt happens while the mutex is held.
>>     This stops the other threads until all the softint processing
>>     has finished.
>> 2) An ethernet interrupt (and softint) runs on a thread that is
>>     waiting for the mutex.
>>     (Or on the cpu that the thread's processor affinity ties it to.)
>>     In this case the 'fair' (ticket) mutex code won't let any other
>>     thread acquire the mutex.
>>     So again everything stops until the softints all complete.
>>
>> The second one is also a problem when trying to wake up all
>> the threads (eg after adding a lot of items to the list).
>> The ticket locks force them to wake in order, but
>> sometimes the 'thundering herd' would work better.
>>
>> IIRC this is actually worse for processes running under the RT
>> scheduler (without CONFIG_PREEMPT) because the they are almost
>> always scheduled on the same cpu they ran on last.
>> If it is busy, but cannot be pre-empted, they are not moved
>> to an idle cpu.
>>     
>> To confound things there is a very broken workaround for broken
>> hardware in the driver for the e1000 interface on (at least)
>> Ivy Bridge cpu that can cause the driver to spin for a very
>> long time (IIRC milliseconds) whenever it has to write to a
>> MAC register (ie on every transmit setup).
>>
>> 	David
>>
>> -
>> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
>> Registration No: 1397386 (Wales)
> To make napi threaded, if either irq or softirq thread is entirely ruled
> out, add napi::work that will be queued on a highpri workqueue. It is
> actually a unbound one to facilitate scheduler to catter napi loads on to
> idle CPU cores. What users need to do with the threaded napi
> is s/netif_napi_add/netif_threaded_napi_add/ and no more.
>
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -338,6 +338,9 @@ struct napi_struct {
>   	struct list_head	dev_list;
>   	struct hlist_node	napi_hash_node;
>   	unsigned int		napi_id;
> +#ifdef CONFIG_THREADED_NAPI
> +	struct work_struct	work;
> +#endif
>   };
>   
>   enum {
> @@ -2234,6 +2237,19 @@ static inline void *netdev_priv(const st
>   void netif_napi_add(struct net_device *dev, struct napi_struct *napi,
>   		    int (*poll)(struct napi_struct *, int), int weight);
>   
> +#ifdef CONFIG_THREADED_NAPI
> +void netif_threaded_napi_add(struct net_device *dev, struct napi_struct *napi,
> +		    int (*poll)(struct napi_struct *, int), int weight);
> +#else
> +static inline void netif_threaded_napi_add(struct net_device *dev,
> +					struct napi_struct *napi,
> +					int (*poll)(struct napi_struct *, int),
> +					int weight)
> +{
> +	netif_napi_add(dev, napi, poll, weight);
> +}
> +#endif
> +
>   /**
>    *	netif_tx_napi_add - initialize a NAPI context
>    *	@dev:  network device
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -6277,6 +6277,61 @@ static int process_backlog(struct napi_s
>   	return work;
>   }
>   
> +#ifdef CONFIG_THREADED_NAPI
> +/* unbound highpri workqueue for threaded napi */
> +static struct workqueue_struct *napi_workq;
> +
> +static void napi_workfn(struct work_struct *work)
> +{
> +	struct napi_struct *n = container_of(work, struct napi_struct, work);
> +
> +	for (;;) {
> +		if (!test_bit(NAPI_STATE_SCHED, &n->state))
> +			return;
> +
> +		if (n->poll(n, n->weight) < n->weight)
> +			return;
> +
> +		if (need_resched()) {
> +			/*
> +			 * have to pay for the latency of task switch even if
> +			 * napi is scheduled
> +			 */
> +			if (test_bit(NAPI_STATE_SCHED, &n->state))
> +				queue_work(napi_workq, work);
> +			return;
> +		}
> +	}
> +}
> +
> +void netif_threaded_napi_add(struct net_device *dev,
> +				struct napi_struct *napi,
> +				int (*poll)(struct napi_struct *, int),
> +				int weight)
> +{
> +	netif_napi_add(dev, napi, poll, weight);
> +	INIT_WORK(&napi->work, napi_workfn);
> +}
> +
> +static inline bool is_threaded_napi(struct napi_struct *n)
> +{
> +	return n->work.func == napi_workfn;
> +}
> +
> +static inline void threaded_napi_sched(struct napi_struct *n)
> +{
> +	if (is_threaded_napi(n))
> +		queue_work(napi_workq, &n->work);
> +	else
> +		____napi_schedule(this_cpu_ptr(&softnet_data), n);
> +}
> +#else
> +static inline void threaded_napi_sched(struct napi_struct *n)
> +{
> +	____napi_schedule(this_cpu_ptr(&softnet_data), n);
> +}
> +#endif
> +
>   /**
>    * __napi_schedule - schedule for receive
>    * @n: entry to schedule
> @@ -6289,7 +6344,7 @@ void __napi_schedule(struct napi_struct
>   	unsigned long flags;
>   
>   	local_irq_save(flags);
> -	____napi_schedule(this_cpu_ptr(&softnet_data), n);
> +	threaded_napi_sched(n);
>   	local_irq_restore(flags);
>   }
>   EXPORT_SYMBOL(__napi_schedule);
> @@ -6335,7 +6390,7 @@ EXPORT_SYMBOL(napi_schedule_prep);
>    */
>   void __napi_schedule_irqoff(struct napi_struct *n)
>   {
> -	____napi_schedule(this_cpu_ptr(&softnet_data), n);
> +	threaded_napi_sched(n);
>   }
>   EXPORT_SYMBOL(__napi_schedule_irqoff);
>   
> @@ -10685,6 +10740,10 @@ static int __init net_dev_init(void)
>   		sd->backlog.weight = weight_p;
>   	}
>   
> +#ifdef CONFIG_THREADED_NAPI
> +	napi_workq = alloc_workqueue("napi_workq", WQ_UNBOUND | WQ_HIGHPRI,
> +					    WQ_UNBOUND_MAX_ACTIVE);
> +#endif
>   	dev_boot_phase = 0;
>   
>   	/* The loopback device is special if any other network devices
>
>
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
>


From hdanton at sina.com  Sat Jul 25 08:25:01 2020
From: hdanton at sina.com (Hillf Danton)
Date: Sat, 25 Jul 2020 20:25:01 +0800
Subject: [RFC 0/7] Add support to process rx packets in thread
In-Reply-To: <8359a849-2b8a-c842-a501-c6cb6966e345@dd-wrt.com>
References: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
 <20200721172514.GT1339445@lunn.ch> <20200725081633.7432-1-hdanton@sina.com>
Message-ID: <20200725122501.15000-1-hdanton@sina.com>


On Sat, 25 Jul 2020 12:38:00 +0200 Sebastian Gottschall wrote:
> you may consider this
> 
> https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1142611.html 
> <https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1142611.html>

Thanks very much for your link.

> years ago someone already wanted to bring this feature upstream, but it 
> was denied. i already tested this patch the last 2 days and it worked so 
> far (with some little modifications)
> so such a solution existed already and may be considered here

I don't see outstanding difference in principle from Paolo's work in
2016 except for the use of kthread_create() and friends because kworker 
made use of them even before 2016. This is a simpler one as shown by
the diff stat in his cover letter.

Paolo, feel free to correct me if I misread anything.

Finally I don't see the need to add sysfs attr, given CONFIG_THREADED_NAPI
in this work.

BTW let us know if anyone has plans to pick up the 2016 RFC.

Hillf

Paolo Abeni (2):
  net: implement threaded-able napi poll loop support
  net: add sysfs attribute to control napi threaded mode

 include/linux/netdevice.h |   4 ++
 net/core/dev.c            | 113 ++++++++++++++++++++++++++++++++++++++++++++++
 net/core/net-sysfs.c      | 102 +++++++++++++++++++++++++++++++++++++++++
 3 files changed, 219 insertions(+)
> 
> Sebastian
> 
> 
> someone
> 
> Am 25.07.2020 um 10:16 schrieb Hillf Danton:
> > On Wed, 22 Jul 2020 09:12:42 +0000 David Laight wrote:
> >>> On 21 July 2020 18:25 Andrew Lunn wrote:
> >>>
> >>> On Tue, Jul 21, 2020 at 10:44:19PM +0530, Rakesh Pillai wrote:
> >>>> NAPI gets scheduled on the CPU core which got the
> >>>> interrupt. The linux scheduler cannot move it to a
> >>>> different core, even if the CPU on which NAPI is running
> >>>> is heavily loaded. This can lead to degraded wifi
> >>>> performance when running traffic at peak data rates.
> >>>>
> >>>> A thread on the other hand can be moved to different
> >>>> CPU cores, if the one on which its running is heavily
> >>>> loaded. During high incoming data traffic, this gives
> >>>> better performance, since the thread can be moved to a
> >>>> less loaded or sometimes even a more powerful CPU core
> >>>> to account for the required CPU performance in order
> >>>> to process the incoming packets.
> >>>>
> >>>> This patch series adds the support to use a high priority
> >>>> thread to process the incoming packets, as opposed to
> >>>> everything being done in NAPI context.
> >>> I don't see why this problem is limited to the ath10k driver. I expect
> >>> it applies to all drivers using NAPI. So shouldn't you be solving this
> >>> in the NAPI core? Allow a driver to request the NAPI core uses a
> >>> thread?
> >> It's not just NAPI the problem is with the softint processing.
> >> I suspect a lot of systems would work better if it ran as
> >> a (highish priority) kernel thread.
> > Hi folks
> >
> > Below is a minimunm poc implementation I can imagine on top of workqueue
> > to make napi threaded. Thoughts are appreciated.
> >
> >> I've had to remove the main locks from a multi-threaded application
> >> and replace them with atomic counters.
> >> Consider what happens when the threads remove items from a shared
> >> work list.
> >> The code looks like:
> >> 	mutex_enter();
> >> 	remove_item_from_list();
> >> 	mutex_exit().
> >> The mutex is only held for a few instructions, so while you'd expect
> >> the cache line to be 'hot' you wouldn't get real contention.
> >> However the following scenarios happen:
> >> 1) An ethernet interrupt happens while the mutex is held.
> >>     This stops the other threads until all the softint processing
> >>     has finished.
> >> 2) An ethernet interrupt (and softint) runs on a thread that is
> >>     waiting for the mutex.
> >>     (Or on the cpu that the thread's processor affinity ties it to.)
> >>     In this case the 'fair' (ticket) mutex code won't let any other
> >>     thread acquire the mutex.
> >>     So again everything stops until the softints all complete.
> >>
> >> The second one is also a problem when trying to wake up all
> >> the threads (eg after adding a lot of items to the list).
> >> The ticket locks force them to wake in order, but
> >> sometimes the 'thundering herd' would work better.
> >>
> >> IIRC this is actually worse for processes running under the RT
> >> scheduler (without CONFIG_PREEMPT) because the they are almost
> >> always scheduled on the same cpu they ran on last.
> >> If it is busy, but cannot be pre-empted, they are not moved
> >> to an idle cpu.
> >>     
> >> To confound things there is a very broken workaround for broken
> >> hardware in the driver for the e1000 interface on (at least)
> >> Ivy Bridge cpu that can cause the driver to spin for a very
> >> long time (IIRC milliseconds) whenever it has to write to a
> >> MAC register (ie on every transmit setup).
> >>
> >> 	David
> >>
> >> -
> >> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> >> Registration No: 1397386 (Wales)
> >>
> >>
> > To make napi threaded, if either irq or softirq thread is entirely ruled
> > out, add napi::work that will be queued on a highpri workqueue. It is
> > actually a unbound one to facilitate scheduler to catter napi loads on to
> > idle CPU cores. What users need to do with the threaded napi
> > is s/netif_napi_add/netif_threaded_napi_add/ and no more.
> >
> > --- a/include/linux/netdevice.h
> > +++ b/include/linux/netdevice.h
> > @@ -338,6 +338,9 @@ struct napi_struct {
> >   	struct list_head	dev_list;
> >   	struct hlist_node	napi_hash_node;
> >   	unsigned int		napi_id;
> > +#ifdef CONFIG_THREADED_NAPI
> > +	struct work_struct	work;
> > +#endif
> >   };
> >   
> >   enum {
> > @@ -2234,6 +2237,19 @@ static inline void *netdev_priv(const st
> >   void netif_napi_add(struct net_device *dev, struct napi_struct *napi,
> >   		    int (*poll)(struct napi_struct *, int), int weight);
> >   
> > +#ifdef CONFIG_THREADED_NAPI
> > +void netif_threaded_napi_add(struct net_device *dev, struct napi_struct *napi,
> > +		    int (*poll)(struct napi_struct *, int), int weight);
> > +#else
> > +static inline void netif_threaded_napi_add(struct net_device *dev,
> > +					struct napi_struct *napi,
> > +					int (*poll)(struct napi_struct *, int),
> > +					int weight)
> > +{
> > +	netif_napi_add(dev, napi, poll, weight);
> > +}
> > +#endif
> > +
> >   /**
> >    *	netif_tx_napi_add - initialize a NAPI context
> >    *	@dev:  network device
> > --- a/net/core/dev.c
> > +++ b/net/core/dev.c
> > @@ -6277,6 +6277,61 @@ static int process_backlog(struct napi_s
> >   	return work;
> >   }
> >   
> > +#ifdef CONFIG_THREADED_NAPI
> > +/* unbound highpri workqueue for threaded napi */
> > +static struct workqueue_struct *napi_workq;
> > +
> > +static void napi_workfn(struct work_struct *work)
> > +{
> > +	struct napi_struct *n = container_of(work, struct napi_struct, work);
> > +
> > +	for (;;) {
> > +		if (!test_bit(NAPI_STATE_SCHED, &n->state))
> > +			return;
> > +
> > +		if (n->poll(n, n->weight) < n->weight)
> > +			return;
> > +
> > +		if (need_resched()) {
> > +			/*
> > +			 * have to pay for the latency of task switch even if
> > +			 * napi is scheduled
> > +			 */
> > +			if (test_bit(NAPI_STATE_SCHED, &n->state))
> > +				queue_work(napi_workq, work);
> > +			return;
> > +		}
> > +	}
> > +}
> > +
> > +void netif_threaded_napi_add(struct net_device *dev,
> > +				struct napi_struct *napi,
> > +				int (*poll)(struct napi_struct *, int),
> > +				int weight)
> > +{
> > +	netif_napi_add(dev, napi, poll, weight);
> > +	INIT_WORK(&napi->work, napi_workfn);
> > +}
> > +
> > +static inline bool is_threaded_napi(struct napi_struct *n)
> > +{
> > +	return n->work.func == napi_workfn;
> > +}
> > +
> > +static inline void threaded_napi_sched(struct napi_struct *n)
> > +{
> > +	if (is_threaded_napi(n))
> > +		queue_work(napi_workq, &n->work);
> > +	else
> > +		____napi_schedule(this_cpu_ptr(&softnet_data), n);
> > +}
> > +#else
> > +static inline void threaded_napi_sched(struct napi_struct *n)
> > +{
> > +	____napi_schedule(this_cpu_ptr(&softnet_data), n);
> > +}
> > +#endif
> > +
> >   /**
> >    * __napi_schedule - schedule for receive
> >    * @n: entry to schedule
> > @@ -6289,7 +6344,7 @@ void __napi_schedule(struct napi_struct
> >   	unsigned long flags;
> >   
> >   	local_irq_save(flags);
> > -	____napi_schedule(this_cpu_ptr(&softnet_data), n);
> > +	threaded_napi_sched(n);
> >   	local_irq_restore(flags);
> >   }
> >   EXPORT_SYMBOL(__napi_schedule);
> > @@ -6335,7 +6390,7 @@ EXPORT_SYMBOL(napi_schedule_prep);
> >    */
> >   void __napi_schedule_irqoff(struct napi_struct *n)
> >   {
> > -	____napi_schedule(this_cpu_ptr(&softnet_data), n);
> > +	threaded_napi_sched(n);
> >   }
> >   EXPORT_SYMBOL(__napi_schedule_irqoff);
> >   
> > @@ -10685,6 +10740,10 @@ static int __init net_dev_init(void)
> >   		sd->backlog.weight = weight_p;
> >   	}
> >   
> > +#ifdef CONFIG_THREADED_NAPI
> > +	napi_workq = alloc_workqueue("napi_workq", WQ_UNBOUND | WQ_HIGHPRI,
> > +					    WQ_UNBOUND_MAX_ACTIVE);
> > +#endif
> >   	dev_boot_phase = 0;
> >   
> >   	/* The loopback device is special if any other network devices
> >
> >
> > _______________________________________________
> > ath10k mailing list
> > ath10k at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/ath10k



From s.gottschall at dd-wrt.com  Sat Jul 25 10:08:41 2020
From: s.gottschall at dd-wrt.com (Sebastian Gottschall)
Date: Sat, 25 Jul 2020 16:08:41 +0200
Subject: [RFC 0/7] Add support to process rx packets in thread
In-Reply-To: <8359a849-2b8a-c842-a501-c6cb6966e345@dd-wrt.com>
References: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
 <20200721172514.GT1339445@lunn.ch> <20200725081633.7432-1-hdanton@sina.com>
 <8359a849-2b8a-c842-a501-c6cb6966e345@dd-wrt.com>
Message-ID: <2e443640-c051-2209-8d78-06a8e5944305@dd-wrt.com>


Am 25.07.2020 um 14:25 schrieb Hillf Danton:
> On Sat, 25 Jul 2020 12:38:00 +0200 Sebastian Gottschall wrote:
>> you may consider this
>>
>> https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1142611.html 
>>
>> <https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1142611.html> 
>>
> Thanks very much for your link.
>
>> years ago someone already wanted to bring this feature upstream, but it
>> was denied. i already tested this patch the last 2 days and it worked so
>> far (with some little modifications)
>> so such a solution existed already and may be considered here
> I don't see outstanding difference in principle from Paolo's work in
> 2016 except for the use of kthread_create() and friends because kworker
> made use of them even before 2016. This is a simpler one as shown by
> the diff stat in his cover letter.
i agree. i just can say that i tested this patch recently due this 
discussion here. and it can be changed by sysfs. but it doesnt work for
wifi drivers which are mainly using dummy netdev devices. for this i 
made a small patch to get them working using napi_set_threaded manually 
hardcoded in the drivers. (see patch bellow)
i also tested various networking drivers. one thing i notice doesnt 
work. some napi code is used for tx polling. so from my experience this 
concept just works good for rx with the most drivers.
so far i tested mt76, ath10k and some soc ethernet chipsets with good 
success. on ath10k i had about 10 - 20% performance gain on multicore 
systems. using standard iperf3 with 4 parallel streams.

-5439,7 +5441,7 @@ int napi_set_threaded(struct napi_struct *n, bool
 ??????????????? clear_bit(NAPI_STATE_THREADED, &n->state);

 ??????? /* if the device is initializing, nothing todo */
-?????? if (test_bit(__LINK_STATE_START, &n->dev->state))
+?????? if (test_bit(__LINK_STATE_START, &n->dev->state) && 
n->dev->reg_state != NETREG_DUMMY)
 ??????????????? return 0;

 ??????? napi_thread_stop(n)
;


>
> Paolo, feel free to correct me if I misread anything.
>
> Finally I don't see the need to add sysfs attr, given 
> CONFIG_THREADED_NAPI
> in this work.
>
> BTW let us know if anyone has plans to pick up the 2016 RFC.
>
> Hillf
>
> Paolo Abeni (2):
> ?? net: implement threaded-able napi poll loop support
> ?? net: add sysfs attribute to control napi threaded mode
>
> ? include/linux/netdevice.h |?? 4 ++
> ? net/core/dev.c??????????? | 113 
> ++++++++++++++++++++++++++++++++++++++++++++++
> ? net/core/net-sysfs.c????? | 102 
> +++++++++++++++++++++++++++++++++++++++++
> ? 3 files changed, 219 insertions(+)
>> Sebastian
>>
>>
>> someone
>>
>> Am 25.07.2020 um 10:16 schrieb Hillf Danton:
>>> On Wed, 22 Jul 2020 09:12:42 +0000 David Laight wrote:
>>>>> On 21 July 2020 18:25 Andrew Lunn wrote:
>>>>>
>>>>> On Tue, Jul 21, 2020 at 10:44:19PM +0530, Rakesh Pillai wrote:
>>>>>> NAPI gets scheduled on the CPU core which got the
>>>>>> interrupt. The linux scheduler cannot move it to a
>>>>>> different core, even if the CPU on which NAPI is running
>>>>>> is heavily loaded. This can lead to degraded wifi
>>>>>> performance when running traffic at peak data rates.
>>>>>>
>>>>>> A thread on the other hand can be moved to different
>>>>>> CPU cores, if the one on which its running is heavily
>>>>>> loaded. During high incoming data traffic, this gives
>>>>>> better performance, since the thread can be moved to a
>>>>>> less loaded or sometimes even a more powerful CPU core
>>>>>> to account for the required CPU performance in order
>>>>>> to process the incoming packets.
>>>>>>
>>>>>> This patch series adds the support to use a high priority
>>>>>> thread to process the incoming packets, as opposed to
>>>>>> everything being done in NAPI context.
>>>>> I don't see why this problem is limited to the ath10k driver. I 
>>>>> expect
>>>>> it applies to all drivers using NAPI. So shouldn't you be solving 
>>>>> this
>>>>> in the NAPI core? Allow a driver to request the NAPI core uses a
>>>>> thread?
>>>> It's not just NAPI the problem is with the softint processing.
>>>> I suspect a lot of systems would work better if it ran as
>>>> a (highish priority) kernel thread.
>>> Hi folks
>>>
>>> Below is a minimunm poc implementation I can imagine on top of 
>>> workqueue
>>> to make napi threaded. Thoughts are appreciated.
>>>
>>>> I've had to remove the main locks from a multi-threaded application
>>>> and replace them with atomic counters.
>>>> Consider what happens when the threads remove items from a shared
>>>> work list.
>>>> The code looks like:
>>>> ????mutex_enter();
>>>> ????remove_item_from_list();
>>>> ????mutex_exit().
>>>> The mutex is only held for a few instructions, so while you'd expect
>>>> the cache line to be 'hot' you wouldn't get real contention.
>>>> However the following scenarios happen:
>>>> 1) An ethernet interrupt happens while the mutex is held.
>>>> ???? This stops the other threads until all the softint processing
>>>> ???? has finished.
>>>> 2) An ethernet interrupt (and softint) runs on a thread that is
>>>> ???? waiting for the mutex.
>>>> ???? (Or on the cpu that the thread's processor affinity ties it to.)
>>>> ???? In this case the 'fair' (ticket) mutex code won't let any other
>>>> ???? thread acquire the mutex.
>>>> ???? So again everything stops until the softints all complete.
>>>>
>>>> The second one is also a problem when trying to wake up all
>>>> the threads (eg after adding a lot of items to the list).
>>>> The ticket locks force them to wake in order, but
>>>> sometimes the 'thundering herd' would work better.
>>>>
>>>> IIRC this is actually worse for processes running under the RT
>>>> scheduler (without CONFIG_PREEMPT) because the they are almost
>>>> always scheduled on the same cpu they ran on last.
>>>> If it is busy, but cannot be pre-empted, they are not moved
>>>> to an idle cpu.
>>>> ???? To confound things there is a very broken workaround for broken
>>>> hardware in the driver for the e1000 interface on (at least)
>>>> Ivy Bridge cpu that can cause the driver to spin for a very
>>>> long time (IIRC milliseconds) whenever it has to write to a
>>>> MAC register (ie on every transmit setup).
>>>>
>>>> ????David
>>>>
>>>> -
>>>> Registered Address Lakeside, Bramley Road, Mount Farm, Milton 
>>>> Keynes, MK1 1PT, UK
>>>> Registration No: 1397386 (Wales)
>>>>
>>>>
>>> To make napi threaded, if either irq or softirq thread is entirely 
>>> ruled
>>> out, add napi::work that will be queued on a highpri workqueue. It is
>>> actually a unbound one to facilitate scheduler to catter napi loads 
>>> on to
>>> idle CPU cores. What users need to do with the threaded napi
>>> is s/netif_napi_add/netif_threaded_napi_add/ and no more.
>>>
>>> --- a/include/linux/netdevice.h
>>> +++ b/include/linux/netdevice.h
>>> @@ -338,6 +338,9 @@ struct napi_struct {
>>> ?????? struct list_head??? dev_list;
>>> ?????? struct hlist_node??? napi_hash_node;
>>> ?????? unsigned int??????? napi_id;
>>> +#ifdef CONFIG_THREADED_NAPI
>>> +??? struct work_struct??? work;
>>> +#endif
>>> ?? };
>>> ?? ?? enum {
>>> @@ -2234,6 +2237,19 @@ static inline void *netdev_priv(const st
>>> ?? void netif_napi_add(struct net_device *dev, struct napi_struct 
>>> *napi,
>>> ?????????????? int (*poll)(struct napi_struct *, int), int weight);
>>> ?? +#ifdef CONFIG_THREADED_NAPI
>>> +void netif_threaded_napi_add(struct net_device *dev, struct 
>>> napi_struct *napi,
>>> +??????????? int (*poll)(struct napi_struct *, int), int weight);
>>> +#else
>>> +static inline void netif_threaded_napi_add(struct net_device *dev,
>>> +??????????????????? struct napi_struct *napi,
>>> +??????????????????? int (*poll)(struct napi_struct *, int),
>>> +??????????????????? int weight)
>>> +{
>>> +??? netif_napi_add(dev, napi, poll, weight);
>>> +}
>>> +#endif
>>> +
>>> ?? /**
>>> ??? *??? netif_tx_napi_add - initialize a NAPI context
>>> ??? *??? @dev:? network device
>>> --- a/net/core/dev.c
>>> +++ b/net/core/dev.c
>>> @@ -6277,6 +6277,61 @@ static int process_backlog(struct napi_s
>>> ?????? return work;
>>> ?? }
>>> ?? +#ifdef CONFIG_THREADED_NAPI
>>> +/* unbound highpri workqueue for threaded napi */
>>> +static struct workqueue_struct *napi_workq;
>>> +
>>> +static void napi_workfn(struct work_struct *work)
>>> +{
>>> +??? struct napi_struct *n = container_of(work, struct napi_struct, 
>>> work);
>>> +
>>> +??? for (;;) {
>>> +??????? if (!test_bit(NAPI_STATE_SCHED, &n->state))
>>> +??????????? return;
>>> +
>>> +??????? if (n->poll(n, n->weight) < n->weight)
>>> +??????????? return;
>>> +
>>> +??????? if (need_resched()) {
>>> +??????????? /*
>>> +???????????? * have to pay for the latency of task switch even if
>>> +???????????? * napi is scheduled
>>> +???????????? */
>>> +??????????? if (test_bit(NAPI_STATE_SCHED, &n->state))
>>> +??????????????? queue_work(napi_workq, work);
>>> +??????????? return;
>>> +??????? }
>>> +??? }
>>> +}
>>> +
>>> +void netif_threaded_napi_add(struct net_device *dev,
>>> +??????????????? struct napi_struct *napi,
>>> +??????????????? int (*poll)(struct napi_struct *, int),
>>> +??????????????? int weight)
>>> +{
>>> +??? netif_napi_add(dev, napi, poll, weight);
>>> +??? INIT_WORK(&napi->work, napi_workfn);
>>> +}
>>> +
>>> +static inline bool is_threaded_napi(struct napi_struct *n)
>>> +{
>>> +??? return n->work.func == napi_workfn;
>>> +}
>>> +
>>> +static inline void threaded_napi_sched(struct napi_struct *n)
>>> +{
>>> +??? if (is_threaded_napi(n))
>>> +??????? queue_work(napi_workq, &n->work);
>>> +??? else
>>> +??????? ____napi_schedule(this_cpu_ptr(&softnet_data), n);
>>> +}
>>> +#else
>>> +static inline void threaded_napi_sched(struct napi_struct *n)
>>> +{
>>> +??? ____napi_schedule(this_cpu_ptr(&softnet_data), n);
>>> +}
>>> +#endif
>>> +
>>> ?? /**
>>> ??? * __napi_schedule - schedule for receive
>>> ??? * @n: entry to schedule
>>> @@ -6289,7 +6344,7 @@ void __napi_schedule(struct napi_struct
>>> ?????? unsigned long flags;
>>> ?? ?????? local_irq_save(flags);
>>> -??? ____napi_schedule(this_cpu_ptr(&softnet_data), n);
>>> +??? threaded_napi_sched(n);
>>> ?????? local_irq_restore(flags);
>>> ?? }
>>> ?? EXPORT_SYMBOL(__napi_schedule);
>>> @@ -6335,7 +6390,7 @@ EXPORT_SYMBOL(napi_schedule_prep);
>>> ??? */
>>> ?? void __napi_schedule_irqoff(struct napi_struct *n)
>>> ?? {
>>> -??? ____napi_schedule(this_cpu_ptr(&softnet_data), n);
>>> +??? threaded_napi_sched(n);
>>> ?? }
>>> ?? EXPORT_SYMBOL(__napi_schedule_irqoff);
>>> ?? @@ -10685,6 +10740,10 @@ static int __init net_dev_init(void)
>>> ?????????? sd->backlog.weight = weight_p;
>>> ?????? }
>>> ?? +#ifdef CONFIG_THREADED_NAPI
>>> +??? napi_workq = alloc_workqueue("napi_workq", WQ_UNBOUND | 
>>> WQ_HIGHPRI,
>>> +??????????????????????? WQ_UNBOUND_MAX_ACTIVE);
>>> +#endif
>>> ?????? dev_boot_phase = 0;
>>> ?? ?????? /* The loopback device is special if any other network 
>>> devices
>>>
>>>
>>> _______________________________________________
>>> ath10k mailing list
>>> ath10k at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/ath10k
>


From hdanton at sina.com  Sat Jul 25 10:57:28 2020
From: hdanton at sina.com (Hillf Danton)
Date: Sat, 25 Jul 2020 22:57:28 +0800
Subject: [RFC 0/7] Add support to process rx packets in thread
In-Reply-To: <2e443640-c051-2209-8d78-06a8e5944305@dd-wrt.com>
References: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
 <20200721172514.GT1339445@lunn.ch> <20200725081633.7432-1-hdanton@sina.com>
 <8359a849-2b8a-c842-a501-c6cb6966e345@dd-wrt.com>
Message-ID: <20200725145728.10556-1-hdanton@sina.com>


On Sat, 25 Jul 2020 16:08:41 +0200 Sebastian Gottschall wrote:
> Am 25.07.2020 um 14:25 schrieb Hillf Danton:
> > On Sat, 25 Jul 2020 12:38:00 +0200 Sebastian Gottschall wrote:
> >> you may consider this
> >>
> >> https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1142611.html 
> >>
> >> <https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1142611.html> 
> >>
> > Thanks very much for your link.
> >
> >> years ago someone already wanted to bring this feature upstream, but it
> >> was denied. i already tested this patch the last 2 days and it worked so
> >> far (with some little modifications)
> >> so such a solution existed already and may be considered here
> >
> > I don't see outstanding difference in principle from Paolo's work in
> > 2016 except for the use of kthread_create() and friends because kworker
> > made use of them even before 2016. This is a simpler one as shown by
> > the diff stat in his cover letter.
> >
> i agree. i just can say that i tested this patch recently due this 
> discussion here. and it can be changed by sysfs. but it doesnt work for
> wifi drivers which are mainly using dummy netdev devices. for this i 
> made a small patch to get them working using napi_set_threaded manually 
> hardcoded in the drivers. (see patch bellow)

By CONFIG_THREADED_NAPI, there is no need to consider what you did here
in the napi core because device drivers know better and are responsible
for it before calling napi_schedule(n).

> i also tested various networking drivers. one thing i notice doesnt 
> work. some napi code is used for tx polling. so from my experience this 
> concept just works good for rx with the most drivers.

Drivers are also taking care of the napi::poll cb before calling
netif_threaded_napi_add(), while the core offers napi threads. But these
are the trivial differences from the 2016 RFC AFAICS.

> so far i tested mt76, ath10k and some soc ethernet chipsets with good 
> success. on ath10k i had about 10 - 20% performance gain on multicore 
> systems. using standard iperf3 with 4 parallel streams.

Thanks for sharing the tests.

>
> -5439,7 +5441,7 @@ int napi_set_threaded(struct napi_struct *n, bool
>  ??????????????? clear_bit(NAPI_STATE_THREADED, &n->state);
> 
>  ??????? /* if the device is initializing, nothing todo */
> -?????? if (test_bit(__LINK_STATE_START, &n->dev->state))
> +?????? if (test_bit(__LINK_STATE_START, &n->dev->state) && 
> n->dev->reg_state != NETREG_DUMMY)
>  ??????????????? return 0;
> 
>  ??????? napi_thread_stop(n);



From s.gottschall at dd-wrt.com  Sat Jul 25 11:41:48 2020
From: s.gottschall at dd-wrt.com (Sebastian Gottschall)
Date: Sat, 25 Jul 2020 17:41:48 +0200
Subject: [RFC 0/7] Add support to process rx packets in thread
In-Reply-To: <20200725145728.10556-1-hdanton@sina.com>
References: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
 <20200721172514.GT1339445@lunn.ch> <20200725081633.7432-1-hdanton@sina.com>
 <8359a849-2b8a-c842-a501-c6cb6966e345@dd-wrt.com>
 <20200725145728.10556-1-hdanton@sina.com>
Message-ID: <2664182a-1d03-998d-8eff-8478174a310a@dd-wrt.com>


>> i agree. i just can say that i tested this patch recently due this
>> discussion here. and it can be changed by sysfs. but it doesnt work for
>> wifi drivers which are mainly using dummy netdev devices. for this i
>> made a small patch to get them working using napi_set_threaded manually
>> hardcoded in the drivers. (see patch bellow)
> By CONFIG_THREADED_NAPI, there is no need to consider what you did here
> in the napi core because device drivers know better and are responsible
> for it before calling napi_schedule(n).
yeah. but that approach will not work for some cases. some stupid 
drivers are using locking context in the napi poll function.
in that case the performance will runto shit. i discovered this with the 
mvneta eth driver (marvell) and mt76 tx polling (rx? works)
for mvneta is will cause very high latencies and packet drops. for mt76 
it causes packet stop. doesnt work simply (on all cases no crashes)
so the threading will only work for drivers which are compatible with 
that approach. it cannot be used as drop in replacement from my point of 
view.
its all a question of the driver design


From nbd at nbd.name  Sat Jul 25 13:57:23 2020
From: nbd at nbd.name (Felix Fietkau)
Date: Sat, 25 Jul 2020 19:57:23 +0200
Subject: [RFC 0/7] Add support to process rx packets in thread
In-Reply-To: <20200725081633.7432-1-hdanton@sina.com>
References: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
 <20200721172514.GT1339445@lunn.ch> <20200725081633.7432-1-hdanton@sina.com>
Message-ID: <a50ebfba-9733-48db-c90b-5fc106e67f29@nbd.name>

On 2020-07-25 10:16, Hillf Danton wrote:
> Hi folks
> 
> Below is a minimunm poc implementation I can imagine on top of workqueue
> to make napi threaded. Thoughts are appreciated.
Hi Hillf,

For some reason I don't see your mails on linux-wireless/netdev.
I've cleaned up your implementation a bit and I ran some tests with mt76
on an mt7621 embedded board. The results look pretty nice, performance
is a lot more consistent in my tests now.

Here are the changes that I've made compared to your version:

- remove the #ifdef, I think it's unnecessary
- add a state bit for threaded NAPI
- make netif_threaded_napi_add inline
- run queue_work outside of local_irq_save/restore (it does that
internally already)

If you don't mind, I'd like to propose this to netdev soon. Can I have
your Signed-off-by for that?

Thanks,

- Felix

---
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -347,6 +347,7 @@ struct napi_struct {
 	struct list_head	dev_list;
 	struct hlist_node	napi_hash_node;
 	unsigned int		napi_id;
+	struct work_struct	work;
 };
 
 enum {
@@ -357,6 +358,7 @@ enum {
 	NAPI_STATE_HASHED,	/* In NAPI hash (busy polling possible) */
 	NAPI_STATE_NO_BUSY_POLL,/* Do not add in napi_hash, no busy polling */
 	NAPI_STATE_IN_BUSY_POLL,/* sk_busy_loop() owns this NAPI */
+	NAPI_STATE_THREADED,	/* Use threaded NAPI */
 };
 
 enum {
@@ -367,6 +369,7 @@ enum {
 	NAPIF_STATE_HASHED	 = BIT(NAPI_STATE_HASHED),
 	NAPIF_STATE_NO_BUSY_POLL = BIT(NAPI_STATE_NO_BUSY_POLL),
 	NAPIF_STATE_IN_BUSY_POLL = BIT(NAPI_STATE_IN_BUSY_POLL),
+	NAPIF_STATE_THREADED	 = BIT(NAPI_STATE_THREADED),
 };
 
 enum gro_result {
@@ -2315,6 +2318,26 @@ static inline void *netdev_priv(const struct net_device *dev)
 void netif_napi_add(struct net_device *dev, struct napi_struct *napi,
 		    int (*poll)(struct napi_struct *, int), int weight);
 
+/**
+ *	netif_threaded_napi_add - initialize a NAPI context
+ *	@dev:  network device
+ *	@napi: NAPI context
+ *	@poll: polling function
+ *	@weight: default weight
+ *
+ * This variant of netif_napi_add() should be used from drivers using NAPI
+ * with CPU intensive poll functions.
+ * This will schedule polling from a high priority workqueue that
+ */
+static inline void netif_threaded_napi_add(struct net_device *dev,
+					   struct napi_struct *napi,
+					   int (*poll)(struct napi_struct *, int),
+					   int weight)
+{
+	set_bit(NAPI_STATE_THREADED, &napi->state);
+	netif_napi_add(dev, napi, poll, weight);
+}
+
 /**
  *	netif_tx_napi_add - initialize a NAPI context
  *	@dev:  network device
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -158,6 +158,7 @@ static DEFINE_SPINLOCK(offload_lock);
 struct list_head ptype_base[PTYPE_HASH_SIZE] __read_mostly;
 struct list_head ptype_all __read_mostly;	/* Taps */
 static struct list_head offload_base __read_mostly;
+static struct workqueue_struct *napi_workq;
 
 static int netif_rx_internal(struct sk_buff *skb);
 static int call_netdevice_notifiers_info(unsigned long val,
@@ -6286,6 +6287,11 @@ void __napi_schedule(struct napi_struct *n)
 {
 	unsigned long flags;
 
+	if (test_bit(NAPI_STATE_THREADED, &n->state)) {
+		queue_work(napi_workq, &n->work);
+		return;
+	}
+
 	local_irq_save(flags);
 	____napi_schedule(this_cpu_ptr(&softnet_data), n);
 	local_irq_restore(flags);
@@ -6333,6 +6339,11 @@ EXPORT_SYMBOL(napi_schedule_prep);
  */
 void __napi_schedule_irqoff(struct napi_struct *n)
 {
+	if (test_bit(NAPI_STATE_THREADED, &n->state)) {
+		queue_work(napi_workq, &n->work);
+		return;
+	}
+
 	____napi_schedule(this_cpu_ptr(&softnet_data), n);
 }
 EXPORT_SYMBOL(__napi_schedule_irqoff);
@@ -6601,6 +6612,29 @@ static void init_gro_hash(struct napi_struct *napi)
 	napi->gro_bitmask = 0;
 }
 
+static void napi_workfn(struct work_struct *work)
+{
+	struct napi_struct *n = container_of(work, struct napi_struct, work);
+
+	for (;;) {
+		if (!test_bit(NAPI_STATE_SCHED, &n->state))
+			return;
+
+		if (n->poll(n, n->weight) < n->weight)
+			return;
+
+		if (need_resched()) {
+			/*
+			 * have to pay for the latency of task switch even if
+			 * napi is scheduled
+			 */
+			if (test_bit(NAPI_STATE_SCHED, &n->state))
+				queue_work(napi_workq, work);
+			return;
+		}
+	}
+}
+
 void netif_napi_add(struct net_device *dev, struct napi_struct *napi,
 		    int (*poll)(struct napi_struct *, int), int weight)
 {
@@ -6621,6 +6655,7 @@ void netif_napi_add(struct net_device *dev, struct napi_struct *napi,
 #ifdef CONFIG_NETPOLL
 	napi->poll_owner = -1;
 #endif
+	INIT_WORK(&napi->work, napi_workfn);
 	set_bit(NAPI_STATE_SCHED, &napi->state);
 	napi_hash_add(napi);
 }
@@ -10676,6 +10711,10 @@ static int __init net_dev_init(void)
 		sd->backlog.weight = weight_p;
 	}
 
+	napi_workq = alloc_workqueue("napi_workq", WQ_UNBOUND | WQ_HIGHPRI,
+				     WQ_UNBOUND_MAX_ACTIVE);
+	BUG_ON(!napi_workq);
+
 	dev_boot_phase = 0;
 
 	/* The loopback device is special if any other network devices


From hdanton at sina.com  Sat Jul 25 21:22:44 2020
From: hdanton at sina.com (Hillf Danton)
Date: Sun, 26 Jul 2020 09:22:44 +0800
Subject: [RFC 0/7] Add support to process rx packets in thread
In-Reply-To: <a50ebfba-9733-48db-c90b-5fc106e67f29@nbd.name>
References: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
 <20200721172514.GT1339445@lunn.ch> <20200725081633.7432-1-hdanton@sina.com>
Message-ID: <20200726012244.15264-1-hdanton@sina.com>


Hi Felix,

On Sat, 25 Jul 2020 19:57:23 +0200 Felix Fietkau wrote:
> On 2020-07-25 10:16, Hillf Danton wrote:
> > Hi folks
> > 
> > Below is a minimunm poc implementation I can imagine on top of workqueue
> > to make napi threaded. Thoughts are appreciated.
> > 
> Hi Hillf,
> 
> For some reason I don't see your mails on linux-wireless/netdev.

All is down to my inbox ...

> I've cleaned up your implementation a bit and I ran some tests with mt76
> on an mt7621 embedded board. The results look pretty nice, performance
> is a lot more consistent in my tests now.

Thanks very much for your cleanup and testing.

> Here are the changes that I've made compared to your version:
> 
> - remove the #ifdef, I think it's unnecessary

This makes the code a mile nicer and perhaps I fear pulls some questions
from EricD.

> - add a state bit for threaded NAPI
> - make netif_threaded_napi_add inline
> - run queue_work outside of local_irq_save/restore (it does that
> internally already)
>
> If you don't mind, I'd like to propose this to netdev soon. Can I have
> your Signed-off-by for that?

Feel free to do that. Is it likely for me to select a Cc?

Thanks
Hillf

> Thanks,
> 
> - Felix
> 
> ---
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -347,6 +347,7 @@ struct napi_struct {
>  	struct list_head	dev_list;
>  	struct hlist_node	napi_hash_node;
>  	unsigned int		napi_id;
> +	struct work_struct	work;
>  };
>  
>  enum {
> @@ -357,6 +358,7 @@ enum {
>  	NAPI_STATE_HASHED,	/* In NAPI hash (busy polling possible) */
>  	NAPI_STATE_NO_BUSY_POLL,/* Do not add in napi_hash, no busy polling */
>  	NAPI_STATE_IN_BUSY_POLL,/* sk_busy_loop() owns this NAPI */
> +	NAPI_STATE_THREADED,	/* Use threaded NAPI */
>  };
>  
>  enum {
> @@ -367,6 +369,7 @@ enum {
>  	NAPIF_STATE_HASHED	 = BIT(NAPI_STATE_HASHED),
>  	NAPIF_STATE_NO_BUSY_POLL = BIT(NAPI_STATE_NO_BUSY_POLL),
>  	NAPIF_STATE_IN_BUSY_POLL = BIT(NAPI_STATE_IN_BUSY_POLL),
> +	NAPIF_STATE_THREADED	 = BIT(NAPI_STATE_THREADED),
>  };
>  
>  enum gro_result {
> @@ -2315,6 +2318,26 @@ static inline void *netdev_priv(const struct net_device *dev)
>  void netif_napi_add(struct net_device *dev, struct napi_struct *napi,
>  		    int (*poll)(struct napi_struct *, int), int weight);
>  
> +/**
> + *	netif_threaded_napi_add - initialize a NAPI context
> + *	@dev:  network device
> + *	@napi: NAPI context
> + *	@poll: polling function
> + *	@weight: default weight
> + *
> + * This variant of netif_napi_add() should be used from drivers using NAPI
> + * with CPU intensive poll functions.
> + * This will schedule polling from a high priority workqueue that
> + */
> +static inline void netif_threaded_napi_add(struct net_device *dev,
> +					   struct napi_struct *napi,
> +					   int (*poll)(struct napi_struct *, int),
> +					   int weight)
> +{
> +	set_bit(NAPI_STATE_THREADED, &napi->state);
> +	netif_napi_add(dev, napi, poll, weight);
> +}
> +
>  /**
>   *	netif_tx_napi_add - initialize a NAPI context
>   *	@dev:  network device
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -158,6 +158,7 @@ static DEFINE_SPINLOCK(offload_lock);
>  struct list_head ptype_base[PTYPE_HASH_SIZE] __read_mostly;
>  struct list_head ptype_all __read_mostly;	/* Taps */
>  static struct list_head offload_base __read_mostly;
> +static struct workqueue_struct *napi_workq;

Is __read_mostly missing?

>  static int netif_rx_internal(struct sk_buff *skb);
>  static int call_netdevice_notifiers_info(unsigned long val,
> @@ -6286,6 +6287,11 @@ void __napi_schedule(struct napi_struct *n)
>  {
>  	unsigned long flags;
>  
> +	if (test_bit(NAPI_STATE_THREADED, &n->state)) {
> +		queue_work(napi_workq, &n->work);
> +		return;
> +	}
> +
>  	local_irq_save(flags);
>  	____napi_schedule(this_cpu_ptr(&softnet_data), n);
>  	local_irq_restore(flags);
> @@ -6333,6 +6339,11 @@ EXPORT_SYMBOL(napi_schedule_prep);
>   */
>  void __napi_schedule_irqoff(struct napi_struct *n)
>  {
> +	if (test_bit(NAPI_STATE_THREADED, &n->state)) {
> +		queue_work(napi_workq, &n->work);
> +		return;
> +	}
> +
>  	____napi_schedule(this_cpu_ptr(&softnet_data), n);
>  }
>  EXPORT_SYMBOL(__napi_schedule_irqoff);
> @@ -6601,6 +6612,29 @@ static void init_gro_hash(struct napi_struct *napi)
>  	napi->gro_bitmask = 0;
>  }
>  
> +static void napi_workfn(struct work_struct *work)
> +{
> +	struct napi_struct *n = container_of(work, struct napi_struct, work);
> +
> +	for (;;) {
> +		if (!test_bit(NAPI_STATE_SCHED, &n->state))
> +			return;
> +
> +		if (n->poll(n, n->weight) < n->weight)
> +			return;
> +
> +		if (need_resched()) {
> +			/*
> +			 * have to pay for the latency of task switch even if
> +			 * napi is scheduled
> +			 */
> +			if (test_bit(NAPI_STATE_SCHED, &n->state))
> +				queue_work(napi_workq, work);
> +			return;
> +		}
> +	}
> +}
> +
>  void netif_napi_add(struct net_device *dev, struct napi_struct *napi,
>  		    int (*poll)(struct napi_struct *, int), int weight)
>  {
> @@ -6621,6 +6655,7 @@ void netif_napi_add(struct net_device *dev, struct napi_struct *napi,
>  #ifdef CONFIG_NETPOLL
>  	napi->poll_owner = -1;
>  #endif
> +	INIT_WORK(&napi->work, napi_workfn);
>  	set_bit(NAPI_STATE_SCHED, &napi->state);
>  	napi_hash_add(napi);
>  }
> @@ -10676,6 +10711,10 @@ static int __init net_dev_init(void)
>  		sd->backlog.weight = weight_p;
>  	}
>  
> +	napi_workq = alloc_workqueue("napi_workq", WQ_UNBOUND | WQ_HIGHPRI,
> +				     WQ_UNBOUND_MAX_ACTIVE);
> +	BUG_ON(!napi_workq);
> +
>  	dev_boot_phase = 0;
>  
>  	/* The loopback device is special if any other network devices
> 



From nbd at nbd.name  Sun Jul 26 04:10:15 2020
From: nbd at nbd.name (Felix Fietkau)
Date: Sun, 26 Jul 2020 10:10:15 +0200
Subject: [RFC 0/7] Add support to process rx packets in thread
In-Reply-To: <20200726012244.15264-1-hdanton@sina.com>
References: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
 <20200721172514.GT1339445@lunn.ch> <20200725081633.7432-1-hdanton@sina.com>
 <20200726012244.15264-1-hdanton@sina.com>
Message-ID: <3ce69fb9-f340-d50d-8e77-61c7210a61c6@nbd.name>

On 2020-07-26 03:22, Hillf Danton wrote:
>> - add a state bit for threaded NAPI
>> - make netif_threaded_napi_add inline
>> - run queue_work outside of local_irq_save/restore (it does that
>> internally already)
>>
>> If you don't mind, I'd like to propose this to netdev soon. Can I have
>> your Signed-off-by for that?
> 
> Feel free to do that. Is it likely for me to select a Cc?
Shall I use Signed-off-by: Hillf Danton <hdanton at sina.com>?
What Cc do you want me to add?

>> ---
>> --- a/include/linux/netdevice.h
>> +++ b/include/linux/netdevice.h
>> @@ -347,6 +347,7 @@ struct napi_struct {
>>  	struct list_head	dev_list;
>>  	struct hlist_node	napi_hash_node;
>>  	unsigned int		napi_id;
>> +	struct work_struct	work;
>>  };
>>  
>>  enum {
>> @@ -357,6 +358,7 @@ enum {
>>  	NAPI_STATE_HASHED,	/* In NAPI hash (busy polling possible) */
>>  	NAPI_STATE_NO_BUSY_POLL,/* Do not add in napi_hash, no busy polling */
>>  	NAPI_STATE_IN_BUSY_POLL,/* sk_busy_loop() owns this NAPI */
>> +	NAPI_STATE_THREADED,	/* Use threaded NAPI */
>>  };
>>  
>>  enum {
>> @@ -367,6 +369,7 @@ enum {
>>  	NAPIF_STATE_HASHED	 = BIT(NAPI_STATE_HASHED),
>>  	NAPIF_STATE_NO_BUSY_POLL = BIT(NAPI_STATE_NO_BUSY_POLL),
>>  	NAPIF_STATE_IN_BUSY_POLL = BIT(NAPI_STATE_IN_BUSY_POLL),
>> +	NAPIF_STATE_THREADED	 = BIT(NAPI_STATE_THREADED),
>>  };
>>  
>>  enum gro_result {
>> @@ -2315,6 +2318,26 @@ static inline void *netdev_priv(const struct net_device *dev)
>>  void netif_napi_add(struct net_device *dev, struct napi_struct *napi,
>>  		    int (*poll)(struct napi_struct *, int), int weight);
>>  
>> +/**
>> + *	netif_threaded_napi_add - initialize a NAPI context
>> + *	@dev:  network device
>> + *	@napi: NAPI context
>> + *	@poll: polling function
>> + *	@weight: default weight
>> + *
>> + * This variant of netif_napi_add() should be used from drivers using NAPI
>> + * with CPU intensive poll functions.
>> + * This will schedule polling from a high priority workqueue that
>> + */
>> +static inline void netif_threaded_napi_add(struct net_device *dev,
>> +					   struct napi_struct *napi,
>> +					   int (*poll)(struct napi_struct *, int),
>> +					   int weight)
>> +{
>> +	set_bit(NAPI_STATE_THREADED, &napi->state);
>> +	netif_napi_add(dev, napi, poll, weight);
>> +}
>> +
>>  /**
>>   *	netif_tx_napi_add - initialize a NAPI context
>>   *	@dev:  network device
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -158,6 +158,7 @@ static DEFINE_SPINLOCK(offload_lock);
>>  struct list_head ptype_base[PTYPE_HASH_SIZE] __read_mostly;
>>  struct list_head ptype_all __read_mostly;	/* Taps */
>>  static struct list_head offload_base __read_mostly;
>> +static struct workqueue_struct *napi_workq;
> 
> Is __read_mostly missing?
Yes, thanks. I will add that before sending the patch.

- Felix


From hdanton at sina.com  Sun Jul 26 04:32:39 2020
From: hdanton at sina.com (Hillf Danton)
Date: Sun, 26 Jul 2020 16:32:39 +0800
Subject: [RFC 0/7] Add support to process rx packets in thread
In-Reply-To: <3ce69fb9-f340-d50d-8e77-61c7210a61c6@nbd.name>
References: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
 <20200721172514.GT1339445@lunn.ch> <20200725081633.7432-1-hdanton@sina.com>
 <20200726012244.15264-1-hdanton@sina.com>
Message-ID: <20200726083239.5060-1-hdanton@sina.com>


On Sun, 26 Jul 2020 10:10:15 +0200 Felix Fietkau wrote:
> On 2020-07-26 03:22, Hillf Danton wrote:
> > 
> > Feel free to do that. Is it likely for me to select a Cc?
> > 
> Shall I use Signed-off-by: Hillf Danton <hdanton at sina.com>?

s/Signed-off-by/Cc/

> What Cc do you want me to add?

I prefer Cc over other tags.



From nbd at nbd.name  Sun Jul 26 04:59:27 2020
From: nbd at nbd.name (Felix Fietkau)
Date: Sun, 26 Jul 2020 10:59:27 +0200
Subject: [RFC 0/7] Add support to process rx packets in thread
In-Reply-To: <20200726083239.5060-1-hdanton@sina.com>
References: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
 <20200721172514.GT1339445@lunn.ch> <20200725081633.7432-1-hdanton@sina.com>
 <20200726012244.15264-1-hdanton@sina.com>
 <20200726083239.5060-1-hdanton@sina.com>
Message-ID: <805e66e3-3090-61d2-1fda-50421eb99e3d@nbd.name>

On 2020-07-26 10:32, Hillf Danton wrote:
> 
> On Sun, 26 Jul 2020 10:10:15 +0200 Felix Fietkau wrote:
>> On 2020-07-26 03:22, Hillf Danton wrote:
>> > 
>> > Feel free to do that. Is it likely for me to select a Cc?
>> > 
>> Shall I use Signed-off-by: Hillf Danton <hdanton at sina.com>?
> 
> s/Signed-off-by/Cc/
> 
>> What Cc do you want me to add?
> 
> I prefer Cc over other tags.
Ah, okay. I was planning on adding you as the author of the patch, since
you did most of the work on it. If you want to be attributed as author
(or in Co-developed-by), I'd need your Signed-off-by.

If you don't want that, I can submit it under my name and leave you in
as Cc only.

- Felix


From David.Laight at ACULAB.COM  Sun Jul 26 07:16:00 2020
From: David.Laight at ACULAB.COM (David Laight)
Date: Sun, 26 Jul 2020 11:16:00 +0000
Subject: [RFC 0/7] Add support to process rx packets in thread
In-Reply-To: <2664182a-1d03-998d-8eff-8478174a310a@dd-wrt.com>
References: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
 <20200721172514.GT1339445@lunn.ch> <20200725081633.7432-1-hdanton@sina.com>
 <8359a849-2b8a-c842-a501-c6cb6966e345@dd-wrt.com>
 <20200725145728.10556-1-hdanton@sina.com>
 <2664182a-1d03-998d-8eff-8478174a310a@dd-wrt.com>
Message-ID: <cb54c2746a3d4ce695e3bda8b576b40e@AcuMS.aculab.com>

From: Sebastian Gottschall <s.gottschall at dd-wrt.com>
> Sent: 25 July 2020 16:42
> >> i agree. i just can say that i tested this patch recently due this
> >> discussion here. and it can be changed by sysfs. but it doesnt work for
> >> wifi drivers which are mainly using dummy netdev devices. for this i
> >> made a small patch to get them working using napi_set_threaded manually
> >> hardcoded in the drivers. (see patch bellow)

> > By CONFIG_THREADED_NAPI, there is no need to consider what you did here
> > in the napi core because device drivers know better and are responsible
> > for it before calling napi_schedule(n).

> yeah. but that approach will not work for some cases. some stupid
> drivers are using locking context in the napi poll function.
> in that case the performance will runto shit. i discovered this with the
> mvneta eth driver (marvell) and mt76 tx polling (rx? works)
> for mvneta is will cause very high latencies and packet drops. for mt76
> it causes packet stop. doesnt work simply (on all cases no crashes)
> so the threading will only work for drivers which are compatible with
> that approach. it cannot be used as drop in replacement from my point of
> view.
> its all a question of the driver design

Why should it make (much) difference whether the napi callbacks (etc)
are done in the context of the interrupted process or that of a
specific kernel thread.
The process flags (or whatever) can even be set so that it appears
to be the expected 'softint' context.

In any case running NAPI from a thread will just show up the next
piece of code that runs for ages in softint context.
I think I've seen the tail end of memory being freed under rcu
finally happening under softint and taking absolutely ages.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

From pillair at codeaurora.org  Sun Jul 26 12:19:51 2020
From: pillair at codeaurora.org (Rakesh Pillai)
Date: Sun, 26 Jul 2020 21:49:51 +0530
Subject: [RFC 1/7] mac80211: Add check for napi handle before WARN_ON
References: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>		
 <1595351666-28193-2-git-send-email-pillair@codeaurora.org>	
 <0dbdef912f9d61521011f638200fd451a3530568.camel@sipsolutions.net>	
 <003201d6611e$c54a1c90$4fde55b0$@codeaurora.org>
 <ce380ea1fd1f5db40a92f67673f070a1f88eee50.camel@sipsolutions.net> 
Message-ID: <000e01d66368$9a6ece70$cf4c6b50$@codeaurora.org>



> -----Original Message-----
> From: Rakesh Pillai <pillair at codeaurora.org>
> Sent: Friday, July 24, 2020 11:51 AM
> To: 'Johannes Berg' <johannes at sipsolutions.net>;
> 'ath10k at lists.infradead.org' <ath10k at lists.infradead.org>
> Cc: 'linux-wireless at vger.kernel.org' <linux-wireless at vger.kernel.org>;
> 'linux-kernel at vger.kernel.org' <linux-kernel at vger.kernel.org>;
> 'kvalo at codeaurora.org' <kvalo at codeaurora.org>; 'davem at davemloft.net'
> <davem at davemloft.net>; 'kuba at kernel.org' <kuba at kernel.org>;
> 'netdev at vger.kernel.org' <netdev at vger.kernel.org>;
> 'dianders at chromium.org' <dianders at chromium.org>;
> 'evgreen at chromium.org' <evgreen at chromium.org>
> Subject: RE: [RFC 1/7] mac80211: Add check for napi handle before
> WARN_ON
> 
> 
> 
> > -----Original Message-----
> > From: Johannes Berg <johannes at sipsolutions.net>
> > Sent: Friday, July 24, 2020 1:37 AM
> > To: Rakesh Pillai <pillair at codeaurora.org>; ath10k at lists.infradead.org
> > Cc: linux-wireless at vger.kernel.org; linux-kernel at vger.kernel.org;
> > kvalo at codeaurora.org; davem at davemloft.net; kuba at kernel.org;
> > netdev at vger.kernel.org; dianders at chromium.org;
> evgreen at chromium.org
> > Subject: Re: [RFC 1/7] mac80211: Add check for napi handle before
> > WARN_ON
> >
> > On Thu, 2020-07-23 at 23:56 +0530, Rakesh Pillai wrote:
> >
> > > > > -	WARN_ON_ONCE(softirq_count() == 0);
> > > > > +	WARN_ON_ONCE(napi && softirq_count() == 0);
> > > >
> > > > FWIW, I'm pretty sure this is incorrect - we make assumptions on
> > > > softirqs being disabled in mac80211 for serialization and in place of
> > > > some locking, I believe.
> > > >
> > >
> > > I checked this, but let me double confirm.
> > > But after this change, no packet is submitted from driver in a softirq
> > context.
> > > So ideally this should take care of serialization.
> >
> > I'd guess that we have some reliance on BHs already being disabled, for
> > things like u64 sync updates, or whatnot. I mean, we did "rx_ni()" for a
> > reason ... Maybe lockdep can help catch some of the issues.
> >
> > But couldn't you be in a thread and have BHs disabled too?
> 
> This would ideally beat the purpose and possibly hurt the other subsystems
> running on the same core.
> 

Hi Johannes,

We do have the usage of napi_gro_receive and netif_receive_skb in mac80211.
                /* deliver to local stack */
                if (rx->napi)
                        napi_gro_receive(rx->napi, skb);
                else
                        netif_receive_skb(skb);


Also all the rx_handlers are called under the " rx->local->rx_path_lock" lock.
Is the BH disable still required ?


> >
> > johannes




From lkp at intel.com  Sun Jul 26 23:41:13 2020
From: lkp at intel.com (kernel test robot)
Date: Mon, 27 Jul 2020 11:41:13 +0800
Subject: [ath6kl:master-pending] BUILD SUCCESS
 20bc0ea7f0d3ea61945cac2ff0bb840eb1191a7d
Message-ID: <5f1e4cd9.AMWfb7RiLNWstV54%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git  master-pending
branch HEAD: 20bc0ea7f0d3ea61945cac2ff0bb840eb1191a7d  Merge branch 'pending' into master-pending

elapsed time: 2642m

configs tested: 74
configs skipped: 1

The following configs have been built successfully.
More configs may be tested in the coming days.

arm64                            allyesconfig
arm64                               defconfig
arm64                            allmodconfig
arm64                             allnoconfig
arm                                 defconfig
arm                              allyesconfig
arm                              allmodconfig
arm                               allnoconfig
i386                             allyesconfig
i386                                defconfig
i386                              debian-10.3
i386                              allnoconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                              allnoconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                              allnoconfig
m68k                           sun3_defconfig
m68k                                defconfig
m68k                             allyesconfig
nds32                               defconfig
nds32                             allnoconfig
csky                             allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
h8300                            allmodconfig
xtensa                              defconfig
arc                                 defconfig
arc                              allyesconfig
sh                               allmodconfig
sh                                allnoconfig
microblaze                        allnoconfig
nios2                               defconfig
nios2                            allyesconfig
openrisc                            defconfig
c6x                              allyesconfig
c6x                               allnoconfig
openrisc                         allyesconfig
mips                             allyesconfig
mips                              allnoconfig
mips                             allmodconfig
parisc                            allnoconfig
parisc                              defconfig
parisc                           allyesconfig
parisc                           allmodconfig
powerpc                             defconfig
powerpc                          allyesconfig
powerpc                          rhel-kconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
riscv                            allyesconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                            allmodconfig
s390                             allyesconfig
s390                              allnoconfig
s390                             allmodconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
sparc64                             defconfig
sparc64                           allnoconfig
sparc64                          allyesconfig
sparc64                          allmodconfig
x86_64                    rhel-7.6-kselftests
x86_64                               rhel-8.3
x86_64                                  kexec
x86_64                                   rhel
x86_64                                    lkp
x86_64                              fedora-25

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From wgong at codeaurora.org  Mon Jul 27 00:17:36 2020
From: wgong at codeaurora.org (Wen Gong)
Date: Mon, 27 Jul 2020 12:17:36 +0800
Subject: [PATCH v2 0/2] ath10k: SAR power limit vendor command
Message-ID: <1595823458-3926-1-git-send-email-wgong@codeaurora.org>

v2: change description of "nl80211: vendor-cmd: qca: add dynamic SAR power limits"
remove ATH10K_WMI_SAR_*G_0_MASK of wmi.h

here's a patchset adding dynamic SAR power limit vendor command to
ath10k. This follows the new process documented in the wiki:

https://wireless.wiki.kernel.org/en/developers/documentation/nl80211#vendor-specific_api

Wen Gong (2):
  nl80211: vendor-cmd: qca: add dynamic SAR power limits
  ath10k: allow dynamic SAR power limits to be configured

 drivers/net/wireless/ath/ath10k/Makefile |   1 +
 drivers/net/wireless/ath/ath10k/core.c   |   2 +
 drivers/net/wireless/ath/ath10k/core.h   |   2 +
 drivers/net/wireless/ath/ath10k/hw.h     |   3 +
 drivers/net/wireless/ath/ath10k/mac.c    |  64 +++++++++++++
 drivers/net/wireless/ath/ath10k/mac.h    |   2 +-
 drivers/net/wireless/ath/ath10k/vendor.c | 114 +++++++++++++++++++++++
 drivers/net/wireless/ath/ath10k/vendor.h |  13 +++
 include/uapi/nl80211-vnd-qca.h           |  68 ++++++++++++++
 9 files changed, 268 insertions(+), 1 deletion(-)
 create mode 100644 drivers/net/wireless/ath/ath10k/vendor.c
 create mode 100644 drivers/net/wireless/ath/ath10k/vendor.h
 create mode 100644 include/uapi/nl80211-vnd-qca.h

-- 
2.23.0



From wgong at codeaurora.org  Mon Jul 27 00:17:37 2020
From: wgong at codeaurora.org (Wen Gong)
Date: Mon, 27 Jul 2020 12:17:37 +0800
Subject: [PATCH v2 1/2] nl80211: vendor-cmd: qca: add dynamic SAR power limits
In-Reply-To: <1595823458-3926-1-git-send-email-wgong@codeaurora.org>
References: <1595823458-3926-1-git-send-email-wgong@codeaurora.org>
Message-ID: <1595823458-3926-2-git-send-email-wgong@codeaurora.org>

The vendor commands is to add API for user to configure dynamic SAR
power limits, it will not replace the existing power control
functionality, it is to make more convenient to configure power.

For different chips and drivers, they has different configuration, such
as dBm units, 5G Hz subbands, valid range, etc. so user space can not
know what configuration should be used. If use a common API for all
chips and drivers, then it need a reporting API too, so drivers can
tell what configuration it support. Recently it is better to use this
vendor-cmd for different chips and drivers.

An example of usage(wlan0 is the wireless interface dev name):
iw dev wlan0 vendor send 0x1374 0x92 0x2C 0x00 0x03 0x00 0x14 0x00 0x01
0x00 0x08 0x00 0x07 0x00 0x22 0x00 0x00 0x00 0x08 0x00 0x04 0x00 0x00
0x00 0x00 0x00 0x14 0x00 0x02 0x00 0x08 0x00 0x07 0x00 0x11 0x00 0x00
0x00 0x08 0x00 0x04 0x00 0x01 0x00 0x00 0x00

means of bytes:
0x1374: vendor id
0x92: vendor subcmd id
0x22: 2.4G power limit
0x11: 5G power limit

Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00029.

Signed-off-by: Wen Gong <wgong at codeaurora.org>
Signed-off-by: Kalle Valo <kvalo at codeaurora.org>
---
 include/uapi/nl80211-vnd-qca.h | 68 ++++++++++++++++++++++++++++++++++
 1 file changed, 68 insertions(+)
 create mode 100644 include/uapi/nl80211-vnd-qca.h

diff --git a/include/uapi/nl80211-vnd-qca.h b/include/uapi/nl80211-vnd-qca.h
new file mode 100644
index 000000000000..482c9409a2c0
--- /dev/null
+++ b/include/uapi/nl80211-vnd-qca.h
@@ -0,0 +1,68 @@
+/* SPDX-License-Identifier: ISC */
+/*
+ * Copyright (c) 2019 The Linux Foundation. All rights reserved.
+ */
+
+#ifndef _UAPI_NL80211_VND_QCA_H
+#define _UAPI_NL80211_VND_QCA_H
+
+/* Vendor id to be used in vendor specific command and events to user space
+ * NOTE: The authoritative place for definition of QCA_NL80211_VENDOR_ID,
+ * vendor subcmd definitions prefixed with QCA_NL80211_VENDOR_SUBCMD, and
+ * qca_wlan_vendor_attr is open source file src/common/qca-vendor.h in
+ * git://w1.fi/srv/git/hostap.git; the values here are just a copy of that
+ */
+#define QCA_NL80211_VENDOR_ID 0x001374
+
+/**
+ * enum qca_nl80211_vendor_subcmds - QCA nl80211 vendor command identifiers
+ *
+ *@QCA_NL80211_VENDOR_SUBCMD_SET_SAR_LIMITS and is used to retrieve the
+ *	settings currently in use. The attributes returned by this command are
+ *	defined by enum qca_vendor_attr_sar_limits.
+ */
+enum qca_nl80211_vendor_subcmds {
+	QCA_NL80211_VENDOR_SUBCMD_SET_SAR_LIMITS = 146,
+	};
+
+/**
+ * enum qca_vendor_attr_sar_limits - Attributes for SAR power limits
+ *
+ * @QCA_WLAN_VENDOR_ATTR_SAR_LIMITS_SPEC: Nested array of SAR power
+ *	limit specifications. The number of specifications is
+ *	specified by @QCA_WLAN_VENDOR_ATTR_SAR_LIMITS_NUM_SPECS. Each
+ *	specification contains a set of
+ *	QCA_WLAN_VENDOR_ATTR_SAR_LIMITS_SPEC_* attributes. A
+ *	specification is uniquely identified by the attributes
+ *	%QCA_WLAN_VENDOR_ATTR_SAR_LIMITS_SPEC_BAND and always
+ *	contains as a payload the attribute
+ *	%QCA_WLAN_VENDOR_ATTR_SAR_LIMITS_SPEC_POWER_LIMIT.
+ *
+ * @QCA_WLAN_VENDOR_ATTR_SAR_LIMITS_SPEC_BAND: Optional (u32) value to
+ *	indicate for which band this specification applies. Valid
+ *	values are enumerated in enum %nl80211_band (although not all
+ *	bands may be supported by a given device). If the attribute is
+ *	not supplied then the specification will be applied to all
+ *	supported bands.
+ *
+ * @QCA_WLAN_VENDOR_ATTR_SAR_LIMITS_SPEC_POWER_LIMIT: Required (u32)
+ *	value to specify the actual power limit value in units of 0.5
+ *	dBm (i.e., a value of 11 represents 5.5 dBm).
+ *	This is required, when %QCA_WLAN_VENDOR_ATTR_SAR_LIMITS_SELECT is
+ *	%QCA_WLAN_VENDOR_ATTR_SAR_LIMITS_SELECT_USER.
+ *
+ * These attributes are used with %QCA_NL80211_VENDOR_SUBCMD_SET_SAR_LIMITS
+ * and %QCA_NL80211_VENDOR_SUBCMD_GET_SAR_LIMITS.
+ */
+enum qca_vendor_attr_sar_limits {
+	QCA_WLAN_VENDOR_ATTR_SAR_LIMITS_INVALID = 0,
+	QCA_WLAN_VENDOR_ATTR_SAR_LIMITS_SPEC = 3,
+	QCA_WLAN_VENDOR_ATTR_SAR_LIMITS_SPEC_BAND = 4,
+	QCA_WLAN_VENDOR_ATTR_SAR_LIMITS_SPEC_POWER_LIMIT = 7,
+
+	QCA_WLAN_VENDOR_ATTR_SAR_LIMITS_AFTER_LAST,
+	QCA_WLAN_VENDOR_ATTR_SAR_LIMITS_MAX =
+		QCA_WLAN_VENDOR_ATTR_SAR_LIMITS_AFTER_LAST - 1
+};
+
+#endif /* _UAPI_NL80211_VND_QCA_H_ */
-- 
2.23.0



From wgong at codeaurora.org  Mon Jul 27 00:17:38 2020
From: wgong at codeaurora.org (Wen Gong)
Date: Mon, 27 Jul 2020 12:17:38 +0800
Subject: [PATCH v2 2/2] ath10k: allow dynamic SAR power limits to be configured
In-Reply-To: <1595823458-3926-1-git-send-email-wgong@codeaurora.org>
References: <1595823458-3926-1-git-send-email-wgong@codeaurora.org>
Message-ID: <1595823458-3926-3-git-send-email-wgong@codeaurora.org>

Add support for a vendor command for STATION, the command
QCA_NL80211_VENDOR_SUBCMD_SET_SAR_LIMITS which is already defined in
git://w1.fi/hostap.git (src/command/qca-vendor.h). This allows user
space to configure power limits for 2.4 GHz and 5 GHz bands.

ath10k set pdev parameter WMI_PDEV_PARAM_TXPOWER_LIMIT2G and
WMI_PDEV_PARAM_TXPOWER_LIMIT5G to firmware, the 2 value will
be used as one input source to affect the tx power.

When QCA_NL80211_VENDOR_SUBCMD_SET_SAR_LIMITS set to ath10k, it will
be saved the 2.4G and 5G limit value, If STATION is connected meanwhile,
then the 2.4G and 5G WMI command will be set to firmware, otherwise
it will not set to firmware at this moment. When STATION connect
next time, it will set to firmware.

Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00029.

Signed-off-by: Wen Gong <wgong at codeaurora.org>
Signed-off-by: Kalle Valo <kvalo at codeaurora.org>
---
 drivers/net/wireless/ath/ath10k/Makefile |   1 +
 drivers/net/wireless/ath/ath10k/core.c   |   2 +
 drivers/net/wireless/ath/ath10k/core.h   |   2 +
 drivers/net/wireless/ath/ath10k/hw.h     |   3 +
 drivers/net/wireless/ath/ath10k/mac.c    |  64 +++++++++++++
 drivers/net/wireless/ath/ath10k/mac.h    |   2 +-
 drivers/net/wireless/ath/ath10k/vendor.c | 114 +++++++++++++++++++++++
 drivers/net/wireless/ath/ath10k/vendor.h |  13 +++
 8 files changed, 200 insertions(+), 1 deletion(-)
 create mode 100644 drivers/net/wireless/ath/ath10k/vendor.c
 create mode 100644 drivers/net/wireless/ath/ath10k/vendor.h

diff --git a/drivers/net/wireless/ath/ath10k/Makefile b/drivers/net/wireless/ath/ath10k/Makefile
index 142c777b287f..6cdc7eba5d25 100644
--- a/drivers/net/wireless/ath/ath10k/Makefile
+++ b/drivers/net/wireless/ath/ath10k/Makefile
@@ -13,6 +13,7 @@ ath10k_core-y += mac.o \
 		 bmi.o \
 		 hw.o \
 		 p2p.o \
+		 vendor.o \
 		 swap.o
 
 ath10k_core-$(CONFIG_ATH10K_SPECTRAL) += spectral.o
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 22b6937ac225..1bab901a28ab 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -25,6 +25,7 @@
 #include "testmode.h"
 #include "wmi-ops.h"
 #include "coredump.h"
+#include "vendor.h"
 
 unsigned int ath10k_debug_mask;
 EXPORT_SYMBOL(ath10k_debug_mask);
@@ -191,6 +192,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 		.tx_stats_over_pktlog = false,
 		.bmi_large_size_download = true,
 		.supports_peer_stats_info = true,
+		.dynamic_sar_support = true,
 	},
 	{
 		.id = QCA6174_HW_2_1_VERSION,
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 5c18f6c20462..c8b8e1398ead 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -1016,6 +1016,8 @@ struct ath10k {
 	u8 ps_state_enable;
 
 	bool nlo_enabled;
+	u32 tx_power_2g_limit;
+	u32 tx_power_5g_limit;
 	bool p2p;
 
 	struct {
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index f16edcb9f326..4bc929e3ed67 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -626,6 +626,9 @@ struct ath10k_hw_params {
 
 	/* provides bitrates for sta_statistics using WMI_TLV_PEER_STATS_INFO_EVENTID */
 	bool supports_peer_stats_info;
+
+	/* support dynamic sar */
+	bool dynamic_sar_support;
 };
 
 struct htt_rx_desc;
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 3e3896214e8b..74ee81e21559 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -24,6 +24,7 @@
 #include "wmi-tlv.h"
 #include "wmi-ops.h"
 #include "wow.h"
+#include "vendor.h"
 
 /*********/
 /* Rates */
@@ -2885,6 +2886,65 @@ static int ath10k_mac_vif_recalc_txbf(struct ath10k *ar,
 	return 0;
 }
 
+static bool ath10k_mac_get_connected(struct ath10k *ar)
+{
+	struct ath10k_vif *arvif;
+
+	list_for_each_entry(arvif, &ar->arvifs, list) {
+		if (arvif->is_up && arvif->vdev_type == WMI_VDEV_TYPE_STA)
+			return true;
+	}
+
+	return false;
+}
+
+int ath10k_mac_set_sar_power_limit(struct ath10k *ar)
+{
+	u32 ret, param, pwr_limit_2G, pwr_limit_5G;
+	bool connected, tx_power_valid;
+
+	if (!ar->hw_params.dynamic_sar_support)
+		return 0;
+
+	connected = ath10k_mac_get_connected(ar);
+	tx_power_valid = (ar->tx_power_2g_limit != 0 && ar->tx_power_5g_limit != 0);
+
+	ath10k_dbg(ar, ATH10K_DBG_MAC, "mac connected %d sar power valid %d\n",
+		   connected, tx_power_valid);
+
+	if (!connected || !tx_power_valid)
+		return 0;
+
+	pwr_limit_2G = ar->tx_power_2g_limit;
+	pwr_limit_5G = ar->tx_power_5g_limit;
+
+	ath10k_dbg(ar, ATH10K_DBG_MAC, "mac sar limits max %d 2.4G %d 5G %d\n",
+		   ar->hw_max_tx_power,
+		   pwr_limit_2G,
+		   pwr_limit_5G);
+
+	param = ar->wmi.pdev_param->txpower_limit2g;
+	ret = ath10k_wmi_pdev_set_param(ar, param, pwr_limit_2G);
+	if (ret) {
+		ath10k_warn(ar, "failed to set 2.4G txpower %d: %d\n",
+			    pwr_limit_2G, ret);
+		return ret;
+	}
+	ath10k_dbg(ar, ATH10K_DBG_MAC, "mac set 2.4G txpower %d success\n", pwr_limit_2G);
+
+	param = ar->wmi.pdev_param->txpower_limit5g;
+	ret = ath10k_wmi_pdev_set_param(ar, param, pwr_limit_5G);
+	if (ret) {
+		ath10k_warn(ar, "failed to set 5G txpower %d: %d\n",
+			    pwr_limit_5G, ret);
+		return ret;
+	}
+
+	ath10k_dbg(ar, ATH10K_DBG_MAC, "mac set 5G txpower %d success\n", pwr_limit_5G);
+
+	return 0;
+}
+
 /* can be called only in mac80211 callbacks due to `key_count` usage */
 static void ath10k_bss_assoc(struct ieee80211_hw *hw,
 			     struct ieee80211_vif *vif,
@@ -2973,6 +3033,8 @@ static void ath10k_bss_assoc(struct ieee80211_hw *hw,
 
 	arvif->is_up = true;
 
+	ath10k_mac_set_sar_power_limit(ar);
+
 	/* Workaround: Some firmware revisions (tested with qca6174
 	 * WLAN.RM.2.0-00073) have buggy powersave state machine and must be
 	 * poked with peer param command.
@@ -9363,6 +9425,8 @@ int ath10k_mac_register(struct ath10k *ar)
 			NL80211_FEATURE_SCAN_RANDOM_MAC_ADDR;
 	}
 
+	ath10k_vendor_register(ar);
+
 	ar->hw->wiphy->cipher_suites = cipher_suites;
 
 	/* QCA988x and QCA6174 family chips do not support CCMP-256, GCMP-128
diff --git a/drivers/net/wireless/ath/ath10k/mac.h b/drivers/net/wireless/ath/ath10k/mac.h
index 98d83a26ea60..54c8cfcef611 100644
--- a/drivers/net/wireless/ath/ath10k/mac.h
+++ b/drivers/net/wireless/ath/ath10k/mac.h
@@ -58,7 +58,7 @@ u8 ath10k_mac_hw_rate_to_idx(const struct ieee80211_supported_band *sband,
 			     u8 hw_rate, bool cck);
 u8 ath10k_mac_bitrate_to_idx(const struct ieee80211_supported_band *sband,
 			     u32 bitrate);
-
+int ath10k_mac_set_sar_power_limit(struct ath10k *ar);
 void ath10k_mac_tx_lock(struct ath10k *ar, int reason);
 void ath10k_mac_tx_unlock(struct ath10k *ar, int reason);
 void ath10k_mac_vif_tx_lock(struct ath10k_vif *arvif, int reason);
diff --git a/drivers/net/wireless/ath/ath10k/vendor.c b/drivers/net/wireless/ath/ath10k/vendor.c
new file mode 100644
index 000000000000..755dbf7146cb
--- /dev/null
+++ b/drivers/net/wireless/ath/ath10k/vendor.c
@@ -0,0 +1,114 @@
+// SPDX-License-Identifier: ISC
+/*
+ * Copyright (c) 2019, The Linux Foundation. All rights reserved.
+ */
+
+#include <net/netlink.h>
+#include <uapi/nl80211-vnd-qca.h>
+
+#include "mac.h"
+#include "debug.h"
+#include "vendor.h"
+
+static const struct nla_policy
+sar_limits_policy[QCA_WLAN_VENDOR_ATTR_SAR_LIMITS_MAX + 1] = {
+	[QCA_WLAN_VENDOR_ATTR_SAR_LIMITS_SPEC_BAND] = {.type = NLA_U32},
+	[QCA_WLAN_VENDOR_ATTR_SAR_LIMITS_SPEC_POWER_LIMIT] = {.type = NLA_U32},
+};
+
+static int ath10k_vendor_set_dynamic_sar_power_limits(struct wiphy *wiphy,
+						      struct wireless_dev *wdev,
+						      const void *data,
+						      int data_len)
+{
+	int rem;
+	struct ieee80211_hw *hw = wiphy_to_ieee80211_hw(wiphy);
+	struct ath10k *ar = hw->priv;
+	struct nlattr *spec[QCA_WLAN_VENDOR_ATTR_SAR_LIMITS_MAX + 1];
+	struct nlattr *tb[QCA_WLAN_VENDOR_ATTR_SAR_LIMITS_MAX + 1];
+	struct nlattr *spec_list;
+	u32 limit;
+	enum nl80211_band band;
+	bool sar_valid = false;
+
+	if (!ar->hw_params.dynamic_sar_support)
+		return -ENOTSUPP;
+
+	if (nla_parse(tb, QCA_WLAN_VENDOR_ATTR_SAR_LIMITS_MAX, data, data_len,
+		      sar_limits_policy, NULL)) {
+		ath10k_warn(ar, "invalid SAR attr\n");
+		return -EINVAL;
+	}
+
+	if (!tb[QCA_WLAN_VENDOR_ATTR_SAR_LIMITS_SPEC]) {
+		ath10k_warn(ar, "invalid SAR specification list\n");
+		return -EINVAL;
+	}
+
+	nla_for_each_nested(spec_list, tb[QCA_WLAN_VENDOR_ATTR_SAR_LIMITS_SPEC], rem) {
+		if (nla_parse(spec,
+			      QCA_WLAN_VENDOR_ATTR_SAR_LIMITS_MAX,
+			      nla_data(spec_list),
+			      nla_len(spec_list),
+			      sar_limits_policy,
+			      NULL)) {
+			ath10k_warn(ar, "nla_parse failed for SAR Spec list\n");
+			return -EINVAL;
+		}
+
+		if (spec[QCA_WLAN_VENDOR_ATTR_SAR_LIMITS_SPEC_POWER_LIMIT]) {
+			limit = nla_get_u32(
+				spec[QCA_WLAN_VENDOR_ATTR_SAR_LIMITS_SPEC_POWER_LIMIT]);
+		} else {
+			ath10k_warn(ar, "not have spec power limit\n");
+			return -EINVAL;
+		}
+
+		if (spec[QCA_WLAN_VENDOR_ATTR_SAR_LIMITS_SPEC_BAND]) {
+			band = nla_get_u32(
+				spec[QCA_WLAN_VENDOR_ATTR_SAR_LIMITS_SPEC_BAND]);
+		} else {
+			/* if QCA_WLAN_VENDOR_ATTR_SAR_LIMITS_SPEC_BAND is
+			 * unset the limit applies to both bands
+			 */
+			if (limit <= ar->hw_max_tx_power) {
+				ar->tx_power_2g_limit = limit;
+				ar->tx_power_5g_limit = limit;
+				sar_valid = true;
+			}
+
+			break;
+		}
+
+		sar_valid = true;
+		if (band == NL80211_BAND_2GHZ && limit <= ar->hw_max_tx_power)
+			ar->tx_power_2g_limit = limit;
+		else if (band == NL80211_BAND_5GHZ && limit <= ar->hw_max_tx_power)
+			ar->tx_power_5g_limit = limit;
+	}
+
+	if (sar_valid)
+		return ath10k_mac_set_sar_power_limit(ar);
+
+	return 0;
+}
+
+static const struct wiphy_vendor_command ath10k_vendor_commands[] = {
+	{
+		.info = {
+			.vendor_id = QCA_NL80211_VENDOR_ID,
+			.subcmd = QCA_NL80211_VENDOR_SUBCMD_SET_SAR_LIMITS,
+		},
+		.flags = WIPHY_VENDOR_CMD_NEED_WDEV |
+			 WIPHY_VENDOR_CMD_NEED_RUNNING,
+		.doit = ath10k_vendor_set_dynamic_sar_power_limits,
+		.policy = sar_limits_policy,
+	}
+};
+
+void ath10k_vendor_register(struct ath10k *ar)
+{
+	ar->hw->wiphy->vendor_commands = ath10k_vendor_commands;
+	ar->hw->wiphy->n_vendor_commands = ARRAY_SIZE(ath10k_vendor_commands);
+}
+
diff --git a/drivers/net/wireless/ath/ath10k/vendor.h b/drivers/net/wireless/ath/ath10k/vendor.h
new file mode 100644
index 000000000000..827614cb6991
--- /dev/null
+++ b/drivers/net/wireless/ath/ath10k/vendor.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: ISC */
+/*
+ * Copyright (c) 2019 The Linux Foundation. All rights reserved.
+ */
+
+#ifndef _VENDOR_H_
+#define _VENDOR_H_
+
+#include <linux/kernel.h>
+
+void ath10k_vendor_register(struct ath10k *ar);
+
+#endif /* _VENDOR_H_ */
-- 
2.23.0



From lkp at intel.com  Mon Jul 27 01:06:16 2020
From: lkp at intel.com (kernel test robot)
Date: Mon, 27 Jul 2020 13:06:16 +0800
Subject: [ath6kl:pending] BUILD SUCCESS
 8d251747ae09ae3505d04bd129dc7100df4cabac
Message-ID: <5f1e60c8.vEnzM2cPrjQjdEkM%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git  pending
branch HEAD: 8d251747ae09ae3505d04bd129dc7100df4cabac  wcn36xx: Use sequence number allocated by mac80211

elapsed time: 2727m

configs tested: 74
configs skipped: 1

The following configs have been built successfully.
More configs may be tested in the coming days.

arm64                            allyesconfig
arm64                               defconfig
arm64                            allmodconfig
arm64                             allnoconfig
arm                                 defconfig
arm                              allyesconfig
arm                              allmodconfig
arm                               allnoconfig
i386                             allyesconfig
i386                                defconfig
i386                              debian-10.3
i386                              allnoconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                              allnoconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                              allnoconfig
m68k                                defconfig
m68k                             allyesconfig
m68k                           sun3_defconfig
nios2                               defconfig
nios2                            allyesconfig
openrisc                            defconfig
c6x                              allyesconfig
c6x                               allnoconfig
openrisc                         allyesconfig
nds32                               defconfig
nds32                             allnoconfig
csky                             allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
h8300                            allmodconfig
xtensa                              defconfig
arc                                 defconfig
arc                              allyesconfig
sh                               allmodconfig
sh                                allnoconfig
microblaze                        allnoconfig
mips                             allyesconfig
mips                              allnoconfig
mips                             allmodconfig
parisc                            allnoconfig
parisc                              defconfig
parisc                           allyesconfig
parisc                           allmodconfig
powerpc                             defconfig
powerpc                          allyesconfig
powerpc                          rhel-kconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
riscv                            allyesconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                            allmodconfig
s390                             allyesconfig
s390                              allnoconfig
s390                             allmodconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
sparc64                             defconfig
sparc64                           allnoconfig
sparc64                          allyesconfig
sparc64                          allmodconfig
x86_64                    rhel-7.6-kselftests
x86_64                               rhel-8.3
x86_64                                  kexec
x86_64                                   rhel
x86_64                                    lkp
x86_64                              fedora-25

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From arumugampetchimuthu at outlook.com  Mon Jul 27 04:22:38 2020
From: arumugampetchimuthu at outlook.com (ARUMUGAM PETCHIMUTHU)
Date: Mon, 27 Jul 2020 08:22:38 +0000
Subject: Throughput issue in qca988x ath10k
Message-ID: <HKAPR02MB4273A0006B76D956AF1936C9BB720@HKAPR02MB4273.apcprd02.prod.outlook.com>

Hi all,
     I'm using Linux Openwrt 4.14.180 in my Routerkit board, with QCA988x 5G supported WiFi card.  I've setup the AP-STA mode(VHT80 MCS5 short GI NSS 2), for the throughput test using iperf3.  But the maximum achievable throughput is only 60Mbps.  Any pointer to things I need to work on, will be much appreciated !

From wenhu.wang at vivo.com  Mon Jul 27 11:03:16 2020
From: wenhu.wang at vivo.com (=?UTF-8?B?546L5paH6JmO?=)
Date: Mon, 27 Jul 2020 23:03:16 +0800 (GMT+08:00)
Subject: =?UTF-8?B?W1BBVENIXSBzb2M6IHFtaTogYWxsb3cgdXNlciB0byBzZXQgaGFuZGxlIHdxIHRvIGhpcHJpbw==?=
Message-ID: <AMoAtwB9DXJsyd-1khUpzqq9.1.1595862196133.Hmail.wenhu.wang@vivo.com>

Currently the qmi_handle is initialized single threaded and strictly
ordered with the active set to 1. This is pretty simple and safe but
sometimes ineffency. So it is better to allow user to decide whether
a high priority workqueue should be used.

Signed-off-by: Wang Wenhu <wenhu.wang at vivo.com>
---
 drivers/net/ipa/ipa_qmi.c             | 4 ++--
 drivers/net/wireless/ath/ath10k/qmi.c | 2 +-
 drivers/net/wireless/ath/ath11k/qmi.c | 2 +-
 drivers/remoteproc/qcom_sysmon.c      | 2 +-
 drivers/slimbus/qcom-ngd-ctrl.c       | 4 ++--
 drivers/soc/qcom/pdr_interface.c      | 4 ++--
 drivers/soc/qcom/qmi_interface.c      | 9 +++++++--
 include/linux/soc/qcom/qmi.h          | 3 ++-
 samples/qmi/qmi_sample_client.c       | 4 ++--
 9 files changed, 20 insertions(+), 14 deletions(-)

diff --git a/drivers/net/ipa/ipa_qmi.c b/drivers/net/ipa/ipa_qmi.c
index 5090f0f923ad..d78b0fe6bd83 100644
--- a/drivers/net/ipa/ipa_qmi.c
+++ b/drivers/net/ipa/ipa_qmi.c
@@ -486,7 +486,7 @@ int ipa_qmi_setup(struct ipa *ipa)
 	 */
 	ret = qmi_handle_init(&ipa_qmi->server_handle,
 			      IPA_QMI_SERVER_MAX_RCV_SZ, &ipa_server_ops,
-			      ipa_server_msg_handlers);
+			      ipa_server_msg_handlers, 0);
 	if (ret)
 		return ret;
 
@@ -500,7 +500,7 @@ int ipa_qmi_setup(struct ipa *ipa)
 	 */
 	ret = qmi_handle_init(&ipa_qmi->client_handle,
 			      IPA_QMI_CLIENT_MAX_RCV_SZ, &ipa_client_ops,
-			      ipa_client_msg_handlers);
+			      ipa_client_msg_handlers, 0);
 	if (ret)
 		goto err_server_handle_release;
 
diff --git a/drivers/net/wireless/ath/ath10k/qmi.c b/drivers/net/wireless/ath/ath10k/qmi.c
index 5468a41e928e..02881882b4d9 100644
--- a/drivers/net/wireless/ath/ath10k/qmi.c
+++ b/drivers/net/wireless/ath/ath10k/qmi.c
@@ -1034,7 +1034,7 @@ int ath10k_qmi_init(struct ath10k *ar, u32 msa_size)
 
 	ret = qmi_handle_init(&qmi->qmi_hdl,
 			      WLFW_BDF_DOWNLOAD_REQ_MSG_V01_MAX_MSG_LEN,
-			      &ath10k_qmi_ops, qmi_msg_handler);
+			      &ath10k_qmi_ops, qmi_msg_handler, 0);
 	if (ret)
 		goto err;
 
diff --git a/drivers/net/wireless/ath/ath11k/qmi.c b/drivers/net/wireless/ath/ath11k/qmi.c
index c00a99ad8dbc..91394d58d36e 100644
--- a/drivers/net/wireless/ath/ath11k/qmi.c
+++ b/drivers/net/wireless/ath/ath11k/qmi.c
@@ -2397,7 +2397,7 @@ int ath11k_qmi_init_service(struct ath11k_base *ab)
 
 	ab->qmi.target_mem_mode = ATH11K_QMI_TARGET_MEM_MODE_DEFAULT;
 	ret = qmi_handle_init(&ab->qmi.handle, ATH11K_QMI_RESP_LEN_MAX,
-			      &ath11k_qmi_ops, ath11k_qmi_msg_handlers);
+			      &ath11k_qmi_ops, ath11k_qmi_msg_handlers, 0);
 	if (ret < 0) {
 		ath11k_warn(ab, "failed to initialize qmi handle\n");
 		return ret;
diff --git a/drivers/remoteproc/qcom_sysmon.c b/drivers/remoteproc/qcom_sysmon.c
index 8d8996d714f0..4ec470e424ef 100644
--- a/drivers/remoteproc/qcom_sysmon.c
+++ b/drivers/remoteproc/qcom_sysmon.c
@@ -614,7 +614,7 @@ struct qcom_sysmon *qcom_add_sysmon_subdev(struct rproc *rproc,
 	}
 
 	ret = qmi_handle_init(&sysmon->qmi, SSCTL_MAX_MSG_LEN, &ssctl_ops,
-			      qmi_indication_handler);
+			      qmi_indication_handler, 0);
 	if (ret < 0) {
 		dev_err(sysmon->dev, "failed to initialize qmi handle\n");
 		kfree(sysmon);
diff --git a/drivers/slimbus/qcom-ngd-ctrl.c b/drivers/slimbus/qcom-ngd-ctrl.c
index 743ee7b4e63f..ba76691fc5a5 100644
--- a/drivers/slimbus/qcom-ngd-ctrl.c
+++ b/drivers/slimbus/qcom-ngd-ctrl.c
@@ -446,7 +446,7 @@ static int qcom_slim_qmi_init(struct qcom_slim_ngd_ctrl *ctrl,
 		return -ENOMEM;
 
 	rc = qmi_handle_init(handle, SLIMBUS_QMI_POWER_REQ_MAX_MSG_LEN,
-				NULL, qcom_slim_qmi_msg_handlers);
+				NULL, qcom_slim_qmi_msg_handlers, 0);
 	if (rc < 0) {
 		dev_err(ctrl->dev, "QMI client init failed: %d\n", rc);
 		goto qmi_handle_init_failed;
@@ -1293,7 +1293,7 @@ static int qcom_slim_ngd_qmi_svc_event_init(struct qcom_slim_ngd_ctrl *ctrl)
 	int ret;
 
 	ret = qmi_handle_init(&qmi->svc_event_hdl, 0,
-				&qcom_slim_ngd_qmi_svc_event_ops, NULL);
+				&qcom_slim_ngd_qmi_svc_event_ops, NULL, 0);
 	if (ret < 0) {
 		dev_err(ctrl->dev, "qmi_handle_init failed: %d\n", ret);
 		return ret;
diff --git a/drivers/soc/qcom/pdr_interface.c b/drivers/soc/qcom/pdr_interface.c
index bdcf16f88a97..cc1cb90c1968 100644
--- a/drivers/soc/qcom/pdr_interface.c
+++ b/drivers/soc/qcom/pdr_interface.c
@@ -685,7 +685,7 @@ struct pdr_handle *pdr_handle_alloc(void (*status)(int state,
 
 	ret = qmi_handle_init(&pdr->locator_hdl,
 			      SERVREG_GET_DOMAIN_LIST_RESP_MAX_LEN,
-			      &pdr_locator_ops, NULL);
+			      &pdr_locator_ops, NULL, 0);
 	if (ret < 0)
 		goto destroy_indack;
 
@@ -696,7 +696,7 @@ struct pdr_handle *pdr_handle_alloc(void (*status)(int state,
 	ret = qmi_handle_init(&pdr->notifier_hdl,
 			      SERVREG_STATE_UPDATED_IND_MAX_LEN,
 			      &pdr_notifier_ops,
-			      qmi_indication_handler);
+			      qmi_indication_handler, 0);
 	if (ret < 0)
 		goto release_qmi_handle;
 
diff --git a/drivers/soc/qcom/qmi_interface.c b/drivers/soc/qcom/qmi_interface.c
index 1a03eaa38c46..01160dbfc4d0 100644
--- a/drivers/soc/qcom/qmi_interface.c
+++ b/drivers/soc/qcom/qmi_interface.c
@@ -609,6 +609,7 @@ static struct socket *qmi_sock_create(struct qmi_handle *qmi,
  * @recv_buf_size: maximum size of incoming message
  * @ops:	reference to callbacks for QRTR notifications
  * @handlers:	NULL-terminated list of QMI message handlers
+ * @hiprio:	whether high priority worker is used for workqueue
  *
  * This initializes the QMI client handle to allow sending and receiving QMI
  * messages. As messages are received the appropriate handler will be invoked.
@@ -617,9 +618,11 @@ static struct socket *qmi_sock_create(struct qmi_handle *qmi,
  */
 int qmi_handle_init(struct qmi_handle *qmi, size_t recv_buf_size,
 		    const struct qmi_ops *ops,
-		    const struct qmi_msg_handler *handlers)
+		    const struct qmi_msg_handler *handlers,
+		    unsigned int hiprio)
 {
 	int ret;
+	unsigned int flags = WQ_UNBOUND;
 
 	mutex_init(&qmi->txn_lock);
 	mutex_init(&qmi->sock_lock);
@@ -647,7 +650,9 @@ int qmi_handle_init(struct qmi_handle *qmi, size_t recv_buf_size,
 	if (!qmi->recv_buf)
 		return -ENOMEM;
 
-	qmi->wq = alloc_workqueue("qmi_msg_handler", WQ_UNBOUND, 1);
+	if (hiprio)
+		flags |= WQ_HIGHPRI;
+	qmi->wq = alloc_workqueue("qmi_msg_handler", flags, 1);
 	if (!qmi->wq) {
 		ret = -ENOMEM;
 		goto err_free_recv_buf;
diff --git a/include/linux/soc/qcom/qmi.h b/include/linux/soc/qcom/qmi.h
index e712f94b89fc..24062fd7163d 100644
--- a/include/linux/soc/qcom/qmi.h
+++ b/include/linux/soc/qcom/qmi.h
@@ -244,7 +244,8 @@ int qmi_add_server(struct qmi_handle *qmi, unsigned int service,
 
 int qmi_handle_init(struct qmi_handle *qmi, size_t max_msg_len,
 		    const struct qmi_ops *ops,
-		    const struct qmi_msg_handler *handlers);
+		    const struct qmi_msg_handler *handlers,
+		    unsigned int hiprio);
 void qmi_handle_release(struct qmi_handle *qmi);
 
 ssize_t qmi_send_request(struct qmi_handle *qmi, struct sockaddr_qrtr *sq,
diff --git a/samples/qmi/qmi_sample_client.c b/samples/qmi/qmi_sample_client.c
index c9e7276c3d83..a91d1633ea38 100644
--- a/samples/qmi/qmi_sample_client.c
+++ b/samples/qmi/qmi_sample_client.c
@@ -463,7 +463,7 @@ static int qmi_sample_probe(struct platform_device *pdev)
 
 	ret = qmi_handle_init(&sample->qmi, TEST_DATA_REQ_MAX_MSG_LEN_V01,
 			      NULL,
-			      qmi_sample_handlers);
+			      qmi_sample_handlers, 0);
 	if (ret < 0)
 		return ret;
 
@@ -590,7 +590,7 @@ static int qmi_sample_init(void)
 	if (ret)
 		goto err_remove_debug_dir;
 
-	ret = qmi_handle_init(&lookup_client, 0, &lookup_ops, NULL);
+	ret = qmi_handle_init(&lookup_client, 0, &lookup_ops, NULL, 0);
 	if (ret < 0)
 		goto err_unregister_driver;
 
-- 
2.17.1




From gustavoars at kernel.org  Mon Jul 27 15:38:21 2020
From: gustavoars at kernel.org (Gustavo A. R. Silva)
Date: Mon, 27 Jul 2020 14:38:21 -0500
Subject: [PATCH][next] ath10k: Use fallthrough pseudo-keyword
Message-ID: <20200727193821.GA981@embeddedor>

Replace the existing /* fall through */ comments and its variants with
the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary
fall-through markings when it is the case.

[1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through

Signed-off-by: Gustavo A. R. Silva <gustavoars at kernel.org>
---
 drivers/net/wireless/ath/ath10k/core.c   |  2 +-
 drivers/net/wireless/ath/ath10k/htt_rx.c |  2 +-
 drivers/net/wireless/ath/ath10k/htt_tx.c |  6 +++---
 drivers/net/wireless/ath/ath10k/mac.c    | 18 +++++++++---------
 drivers/net/wireless/ath/ath10k/wow.c    |  2 +-
 5 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 340ce327ac14..8afb1d5fc9b5 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -2320,7 +2320,7 @@ static void ath10k_core_restart(struct work_struct *work)
 		break;
 	case ATH10K_STATE_RESTARTED:
 		ar->state = ATH10K_STATE_WEDGED;
-		/* fall through */
+		fallthrough;
 	case ATH10K_STATE_WEDGED:
 		ath10k_warn(ar, "device is wedged, will not restart\n");
 		break;
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index d787cbead56a..56e227f2e096 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -3017,7 +3017,7 @@ static int ath10k_htt_rx_in_ord_ind(struct ath10k *ar, struct sk_buff *skb)
 			ath10k_htt_rx_h_enqueue(ar, &amsdu, status);
 			break;
 		case -EAGAIN:
-			/* fall through */
+			fallthrough;
 		default:
 			/* Should not happen. */
 			ath10k_warn(ar, "failed to extract amsdu: %d\n", ret);
diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c b/drivers/net/wireless/ath/ath10k/htt_tx.c
index bbe869575855..1fc0a312ab58 100644
--- a/drivers/net/wireless/ath/ath10k/htt_tx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
@@ -1314,7 +1314,7 @@ static int ath10k_htt_tx_hl(struct ath10k_htt *htt, enum ath10k_hw_txrx_mode txm
 	case ATH10K_HW_TXRX_RAW:
 	case ATH10K_HW_TXRX_NATIVE_WIFI:
 		flags0 |= HTT_DATA_TX_DESC_FLAGS0_MAC_HDR_PRESENT;
-		/* fall through */
+		fallthrough;
 	case ATH10K_HW_TXRX_ETHERNET:
 		flags0 |= SM(txmode, HTT_DATA_TX_DESC_FLAGS0_PKT_TYPE);
 		break;
@@ -1460,7 +1460,7 @@ static int ath10k_htt_tx_32(struct ath10k_htt *htt,
 	case ATH10K_HW_TXRX_RAW:
 	case ATH10K_HW_TXRX_NATIVE_WIFI:
 		flags0 |= HTT_DATA_TX_DESC_FLAGS0_MAC_HDR_PRESENT;
-		/* fall through */
+		fallthrough;
 	case ATH10K_HW_TXRX_ETHERNET:
 		if (ar->hw_params.continuous_frag_desc) {
 			ext_desc_t = htt->frag_desc.vaddr_desc_32;
@@ -1662,7 +1662,7 @@ static int ath10k_htt_tx_64(struct ath10k_htt *htt,
 	case ATH10K_HW_TXRX_RAW:
 	case ATH10K_HW_TXRX_NATIVE_WIFI:
 		flags0 |= HTT_DATA_TX_DESC_FLAGS0_MAC_HDR_PRESENT;
-		/* fall through */
+		fallthrough;
 	case ATH10K_HW_TXRX_ETHERNET:
 		if (ar->hw_params.continuous_frag_desc) {
 			ext_desc_t = htt->frag_desc.vaddr_desc_64;
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 919d15584d4a..7dd2b019f673 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2473,17 +2473,17 @@ ath10k_peer_assoc_h_vht_limit(u16 tx_mcs_set,
 			idx_limit = -1;
 
 		switch (idx_limit) {
-		case 0: /* fall through */
-		case 1: /* fall through */
-		case 2: /* fall through */
-		case 3: /* fall through */
-		case 4: /* fall through */
-		case 5: /* fall through */
-		case 6: /* fall through */
+		case 0:
+		case 1:
+		case 2:
+		case 3:
+		case 4:
+		case 5:
+		case 6:
 		default:
 			/* see ath10k_mac_can_set_bitrate_mask() */
 			WARN_ON(1);
-			/* fall through */
+			fallthrough;
 		case -1:
 			mcs = IEEE80211_VHT_MCS_NOT_SUPPORTED;
 			break;
@@ -4243,7 +4243,7 @@ void __ath10k_scan_finish(struct ath10k *ar)
 		} else if (ar->scan.roc_notify) {
 			ieee80211_remain_on_channel_expired(ar->hw);
 		}
-		/* fall through */
+		fallthrough;
 	case ATH10K_SCAN_STARTING:
 		ar->scan.state = ATH10K_SCAN_IDLE;
 		ar->scan_channel = NULL;
diff --git a/drivers/net/wireless/ath/ath10k/wow.c b/drivers/net/wireless/ath/ath10k/wow.c
index 8c26adddd034..7d65c115669f 100644
--- a/drivers/net/wireless/ath/ath10k/wow.c
+++ b/drivers/net/wireless/ath/ath10k/wow.c
@@ -275,7 +275,7 @@ static int ath10k_vif_wow_set_wakeups(struct ath10k_vif *arvif,
 	switch (arvif->vdev_type) {
 	case WMI_VDEV_TYPE_IBSS:
 		__set_bit(WOW_BEACON_EVENT, &wow_mask);
-		 /* fall through */
+		fallthrough;
 	case WMI_VDEV_TYPE_AP:
 		__set_bit(WOW_DEAUTH_RECVD_EVENT, &wow_mask);
 		__set_bit(WOW_DISASSOC_RECVD_EVENT, &wow_mask);
-- 
2.27.0



From davem at davemloft.net  Mon Jul 27 15:49:42 2020
From: davem at davemloft.net (David Miller)
Date: Mon, 27 Jul 2020 12:49:42 -0700 (PDT)
Subject: [PATCH] soc: qmi: allow user to set handle wq to hiprio
In-Reply-To: <AMoAtwB9DXJsyd-1khUpzqq9.1.1595862196133.Hmail.wenhu.wang@vivo.com>
References: <AMoAtwB9DXJsyd-1khUpzqq9.1.1595862196133.Hmail.wenhu.wang@vivo.com>
Message-ID: <20200727.124942.1829978531845134184.davem@davemloft.net>

From: ??? <wenhu.wang at vivo.com>
Date: Mon, 27 Jul 2020 23:03:16 +0800 (GMT+08:00)

> Currently the qmi_handle is initialized single threaded and strictly
> ordered with the active set to 1. This is pretty simple and safe but
> sometimes ineffency. So it is better to allow user to decide whether
> a high priority workqueue should be used.
> 
> Signed-off-by: Wang Wenhu <wenhu.wang at vivo.com>

Every caller sets the new value to "0", so you should submit this when
you have a cast that actually sets it to "1".

Also, the new argument should be "bool" instead of "unsigned int" and
use "true" and "false" in the callers.

Thank you.


From bjorn.andersson at linaro.org  Mon Jul 27 16:45:21 2020
From: bjorn.andersson at linaro.org (Bjorn Andersson)
Date: Mon, 27 Jul 2020 13:45:21 -0700
Subject: [PATCH] soc: qmi: allow user to set handle wq to hiprio
In-Reply-To: <AMoAtwB9DXJsyd-1khUpzqq9.1.1595862196133.Hmail.wenhu.wang@vivo.com>
References: <AMoAtwB9DXJsyd-1khUpzqq9.1.1595862196133.Hmail.wenhu.wang@vivo.com>
Message-ID: <20200727204521.GB229995@builder.lan>

On Mon 27 Jul 08:03 PDT 2020, ????????? wrote:

> Currently the qmi_handle is initialized single threaded and strictly
> ordered with the active set to 1. This is pretty simple and safe but
> sometimes ineffency. So it is better to allow user to decide whether
> a high priority workqueue should be used.

Can you please describe a scenario where this is needed/desired and
perhaps also comment on why this is not always desired?

Regards,
Bjorn

> 
> Signed-off-by: Wang Wenhu <wenhu.wang at vivo.com>
> ---
>  drivers/net/ipa/ipa_qmi.c             | 4 ++--
>  drivers/net/wireless/ath/ath10k/qmi.c | 2 +-
>  drivers/net/wireless/ath/ath11k/qmi.c | 2 +-
>  drivers/remoteproc/qcom_sysmon.c      | 2 +-
>  drivers/slimbus/qcom-ngd-ctrl.c       | 4 ++--
>  drivers/soc/qcom/pdr_interface.c      | 4 ++--
>  drivers/soc/qcom/qmi_interface.c      | 9 +++++++--
>  include/linux/soc/qcom/qmi.h          | 3 ++-
>  samples/qmi/qmi_sample_client.c       | 4 ++--
>  9 files changed, 20 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/net/ipa/ipa_qmi.c b/drivers/net/ipa/ipa_qmi.c
> index 5090f0f923ad..d78b0fe6bd83 100644
> --- a/drivers/net/ipa/ipa_qmi.c
> +++ b/drivers/net/ipa/ipa_qmi.c
> @@ -486,7 +486,7 @@ int ipa_qmi_setup(struct ipa *ipa)
>  	 */
>  	ret = qmi_handle_init(&ipa_qmi->server_handle,
>  			      IPA_QMI_SERVER_MAX_RCV_SZ, &ipa_server_ops,
> -			      ipa_server_msg_handlers);
> +			      ipa_server_msg_handlers, 0);
>  	if (ret)
>  		return ret;
>  
> @@ -500,7 +500,7 @@ int ipa_qmi_setup(struct ipa *ipa)
>  	 */
>  	ret = qmi_handle_init(&ipa_qmi->client_handle,
>  			      IPA_QMI_CLIENT_MAX_RCV_SZ, &ipa_client_ops,
> -			      ipa_client_msg_handlers);
> +			      ipa_client_msg_handlers, 0);
>  	if (ret)
>  		goto err_server_handle_release;
>  
> diff --git a/drivers/net/wireless/ath/ath10k/qmi.c b/drivers/net/wireless/ath/ath10k/qmi.c
> index 5468a41e928e..02881882b4d9 100644
> --- a/drivers/net/wireless/ath/ath10k/qmi.c
> +++ b/drivers/net/wireless/ath/ath10k/qmi.c
> @@ -1034,7 +1034,7 @@ int ath10k_qmi_init(struct ath10k *ar, u32 msa_size)
>  
>  	ret = qmi_handle_init(&qmi->qmi_hdl,
>  			      WLFW_BDF_DOWNLOAD_REQ_MSG_V01_MAX_MSG_LEN,
> -			      &ath10k_qmi_ops, qmi_msg_handler);
> +			      &ath10k_qmi_ops, qmi_msg_handler, 0);
>  	if (ret)
>  		goto err;
>  
> diff --git a/drivers/net/wireless/ath/ath11k/qmi.c b/drivers/net/wireless/ath/ath11k/qmi.c
> index c00a99ad8dbc..91394d58d36e 100644
> --- a/drivers/net/wireless/ath/ath11k/qmi.c
> +++ b/drivers/net/wireless/ath/ath11k/qmi.c
> @@ -2397,7 +2397,7 @@ int ath11k_qmi_init_service(struct ath11k_base *ab)
>  
>  	ab->qmi.target_mem_mode = ATH11K_QMI_TARGET_MEM_MODE_DEFAULT;
>  	ret = qmi_handle_init(&ab->qmi.handle, ATH11K_QMI_RESP_LEN_MAX,
> -			      &ath11k_qmi_ops, ath11k_qmi_msg_handlers);
> +			      &ath11k_qmi_ops, ath11k_qmi_msg_handlers, 0);
>  	if (ret < 0) {
>  		ath11k_warn(ab, "failed to initialize qmi handle\n");
>  		return ret;
> diff --git a/drivers/remoteproc/qcom_sysmon.c b/drivers/remoteproc/qcom_sysmon.c
> index 8d8996d714f0..4ec470e424ef 100644
> --- a/drivers/remoteproc/qcom_sysmon.c
> +++ b/drivers/remoteproc/qcom_sysmon.c
> @@ -614,7 +614,7 @@ struct qcom_sysmon *qcom_add_sysmon_subdev(struct rproc *rproc,
>  	}
>  
>  	ret = qmi_handle_init(&sysmon->qmi, SSCTL_MAX_MSG_LEN, &ssctl_ops,
> -			      qmi_indication_handler);
> +			      qmi_indication_handler, 0);
>  	if (ret < 0) {
>  		dev_err(sysmon->dev, "failed to initialize qmi handle\n");
>  		kfree(sysmon);
> diff --git a/drivers/slimbus/qcom-ngd-ctrl.c b/drivers/slimbus/qcom-ngd-ctrl.c
> index 743ee7b4e63f..ba76691fc5a5 100644
> --- a/drivers/slimbus/qcom-ngd-ctrl.c
> +++ b/drivers/slimbus/qcom-ngd-ctrl.c
> @@ -446,7 +446,7 @@ static int qcom_slim_qmi_init(struct qcom_slim_ngd_ctrl *ctrl,
>  		return -ENOMEM;
>  
>  	rc = qmi_handle_init(handle, SLIMBUS_QMI_POWER_REQ_MAX_MSG_LEN,
> -				NULL, qcom_slim_qmi_msg_handlers);
> +				NULL, qcom_slim_qmi_msg_handlers, 0);
>  	if (rc < 0) {
>  		dev_err(ctrl->dev, "QMI client init failed: %d\n", rc);
>  		goto qmi_handle_init_failed;
> @@ -1293,7 +1293,7 @@ static int qcom_slim_ngd_qmi_svc_event_init(struct qcom_slim_ngd_ctrl *ctrl)
>  	int ret;
>  
>  	ret = qmi_handle_init(&qmi->svc_event_hdl, 0,
> -				&qcom_slim_ngd_qmi_svc_event_ops, NULL);
> +				&qcom_slim_ngd_qmi_svc_event_ops, NULL, 0);
>  	if (ret < 0) {
>  		dev_err(ctrl->dev, "qmi_handle_init failed: %d\n", ret);
>  		return ret;
> diff --git a/drivers/soc/qcom/pdr_interface.c b/drivers/soc/qcom/pdr_interface.c
> index bdcf16f88a97..cc1cb90c1968 100644
> --- a/drivers/soc/qcom/pdr_interface.c
> +++ b/drivers/soc/qcom/pdr_interface.c
> @@ -685,7 +685,7 @@ struct pdr_handle *pdr_handle_alloc(void (*status)(int state,
>  
>  	ret = qmi_handle_init(&pdr->locator_hdl,
>  			      SERVREG_GET_DOMAIN_LIST_RESP_MAX_LEN,
> -			      &pdr_locator_ops, NULL);
> +			      &pdr_locator_ops, NULL, 0);
>  	if (ret < 0)
>  		goto destroy_indack;
>  
> @@ -696,7 +696,7 @@ struct pdr_handle *pdr_handle_alloc(void (*status)(int state,
>  	ret = qmi_handle_init(&pdr->notifier_hdl,
>  			      SERVREG_STATE_UPDATED_IND_MAX_LEN,
>  			      &pdr_notifier_ops,
> -			      qmi_indication_handler);
> +			      qmi_indication_handler, 0);
>  	if (ret < 0)
>  		goto release_qmi_handle;
>  
> diff --git a/drivers/soc/qcom/qmi_interface.c b/drivers/soc/qcom/qmi_interface.c
> index 1a03eaa38c46..01160dbfc4d0 100644
> --- a/drivers/soc/qcom/qmi_interface.c
> +++ b/drivers/soc/qcom/qmi_interface.c
> @@ -609,6 +609,7 @@ static struct socket *qmi_sock_create(struct qmi_handle *qmi,
>   * @recv_buf_size: maximum size of incoming message
>   * @ops:	reference to callbacks for QRTR notifications
>   * @handlers:	NULL-terminated list of QMI message handlers
> + * @hiprio:	whether high priority worker is used for workqueue
>   *
>   * This initializes the QMI client handle to allow sending and receiving QMI
>   * messages. As messages are received the appropriate handler will be invoked.
> @@ -617,9 +618,11 @@ static struct socket *qmi_sock_create(struct qmi_handle *qmi,
>   */
>  int qmi_handle_init(struct qmi_handle *qmi, size_t recv_buf_size,
>  		    const struct qmi_ops *ops,
> -		    const struct qmi_msg_handler *handlers)
> +		    const struct qmi_msg_handler *handlers,
> +		    unsigned int hiprio)
>  {
>  	int ret;
> +	unsigned int flags = WQ_UNBOUND;
>  
>  	mutex_init(&qmi->txn_lock);
>  	mutex_init(&qmi->sock_lock);
> @@ -647,7 +650,9 @@ int qmi_handle_init(struct qmi_handle *qmi, size_t recv_buf_size,
>  	if (!qmi->recv_buf)
>  		return -ENOMEM;
>  
> -	qmi->wq = alloc_workqueue("qmi_msg_handler", WQ_UNBOUND, 1);
> +	if (hiprio)
> +		flags |= WQ_HIGHPRI;
> +	qmi->wq = alloc_workqueue("qmi_msg_handler", flags, 1);
>  	if (!qmi->wq) {
>  		ret = -ENOMEM;
>  		goto err_free_recv_buf;
> diff --git a/include/linux/soc/qcom/qmi.h b/include/linux/soc/qcom/qmi.h
> index e712f94b89fc..24062fd7163d 100644
> --- a/include/linux/soc/qcom/qmi.h
> +++ b/include/linux/soc/qcom/qmi.h
> @@ -244,7 +244,8 @@ int qmi_add_server(struct qmi_handle *qmi, unsigned int service,
>  
>  int qmi_handle_init(struct qmi_handle *qmi, size_t max_msg_len,
>  		    const struct qmi_ops *ops,
> -		    const struct qmi_msg_handler *handlers);
> +		    const struct qmi_msg_handler *handlers,
> +		    unsigned int hiprio);
>  void qmi_handle_release(struct qmi_handle *qmi);
>  
>  ssize_t qmi_send_request(struct qmi_handle *qmi, struct sockaddr_qrtr *sq,
> diff --git a/samples/qmi/qmi_sample_client.c b/samples/qmi/qmi_sample_client.c
> index c9e7276c3d83..a91d1633ea38 100644
> --- a/samples/qmi/qmi_sample_client.c
> +++ b/samples/qmi/qmi_sample_client.c
> @@ -463,7 +463,7 @@ static int qmi_sample_probe(struct platform_device *pdev)
>  
>  	ret = qmi_handle_init(&sample->qmi, TEST_DATA_REQ_MAX_MSG_LEN_V01,
>  			      NULL,
> -			      qmi_sample_handlers);
> +			      qmi_sample_handlers, 0);
>  	if (ret < 0)
>  		return ret;
>  
> @@ -590,7 +590,7 @@ static int qmi_sample_init(void)
>  	if (ret)
>  		goto err_remove_debug_dir;
>  
> -	ret = qmi_handle_init(&lookup_client, 0, &lookup_ops, NULL);
> +	ret = qmi_handle_init(&lookup_client, 0, &lookup_ops, NULL, 0);
>  	if (ret < 0)
>  		goto err_unregister_driver;
>  
> -- 
> 2.17.1
> 
> 
> 


From pillair at codeaurora.org  Tue Jul 28 12:59:02 2020
From: pillair at codeaurora.org (Rakesh Pillai)
Date: Tue, 28 Jul 2020 22:29:02 +0530
Subject: [RFC 0/7] Add support to process rx packets in thread
In-Reply-To: <cb54c2746a3d4ce695e3bda8b576b40e@AcuMS.aculab.com>
References: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
 <20200721172514.GT1339445@lunn.ch> <20200725081633.7432-1-hdanton@sina.com>
 <8359a849-2b8a-c842-a501-c6cb6966e345@dd-wrt.com>
 <20200725145728.10556-1-hdanton@sina.com>
 <2664182a-1d03-998d-8eff-8478174a310a@dd-wrt.com>
 <cb54c2746a3d4ce695e3bda8b576b40e@AcuMS.aculab.com>
Message-ID: <001001d66500$69a58970$3cf09c50$@codeaurora.org>



> -----Original Message-----
> From: David Laight <David.Laight at ACULAB.COM>
> Sent: Sunday, July 26, 2020 4:46 PM
> To: 'Sebastian Gottschall' <s.gottschall at dd-wrt.com>; Hillf Danton
> <hdanton at sina.com>
> Cc: Andrew Lunn <andrew at lunn.ch>; Rakesh Pillai <pillair at codeaurora.org>;
> netdev at vger.kernel.org; linux-wireless at vger.kernel.org; linux-
> kernel at vger.kernel.org; ath10k at lists.infradead.org;
> dianders at chromium.org; Markus Elfring <Markus.Elfring at web.de>;
> evgreen at chromium.org; kuba at kernel.org; johannes at sipsolutions.net;
> davem at davemloft.net; kvalo at codeaurora.org
> Subject: RE: [RFC 0/7] Add support to process rx packets in thread
> 
> From: Sebastian Gottschall <s.gottschall at dd-wrt.com>
> > Sent: 25 July 2020 16:42
> > >> i agree. i just can say that i tested this patch recently due this
> > >> discussion here. and it can be changed by sysfs. but it doesnt work for
> > >> wifi drivers which are mainly using dummy netdev devices. for this i
> > >> made a small patch to get them working using napi_set_threaded
> manually
> > >> hardcoded in the drivers. (see patch bellow)
> 
> > > By CONFIG_THREADED_NAPI, there is no need to consider what you did
> here
> > > in the napi core because device drivers know better and are responsible
> > > for it before calling napi_schedule(n).
> 
> > yeah. but that approach will not work for some cases. some stupid
> > drivers are using locking context in the napi poll function.
> > in that case the performance will runto shit. i discovered this with the
> > mvneta eth driver (marvell) and mt76 tx polling (rx  works)
> > for mvneta is will cause very high latencies and packet drops. for mt76
> > it causes packet stop. doesnt work simply (on all cases no crashes)
> > so the threading will only work for drivers which are compatible with
> > that approach. it cannot be used as drop in replacement from my point of
> > view.
> > its all a question of the driver design
> 
> Why should it make (much) difference whether the napi callbacks (etc)
> are done in the context of the interrupted process or that of a
> specific kernel thread.
> The process flags (or whatever) can even be set so that it appears
> to be the expected 'softint' context.
> 
> In any case running NAPI from a thread will just show up the next
> piece of code that runs for ages in softint context.
> I think I've seen the tail end of memory being freed under rcu
> finally happening under softint and taking absolutely ages.
> 
> 	David
> 

Hi All,

Is the threaded NAPI change posted to kernel ? 
Is the conclusion of this discussion that " we cannot use threads for processing packets " ??


> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes,
> MK1 1PT, UK
> Registration No: 1397386 (Wales)



From hdanton at sina.com  Tue Jul 28 21:34:25 2020
From: hdanton at sina.com (Hillf Danton)
Date: Wed, 29 Jul 2020 09:34:25 +0800
Subject: [RFC 0/7] Add support to process rx packets in thread
In-Reply-To: <001001d66500$69a58970$3cf09c50$@codeaurora.org>
References: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
 <20200721172514.GT1339445@lunn.ch> <20200725081633.7432-1-hdanton@sina.com>
 <8359a849-2b8a-c842-a501-c6cb6966e345@dd-wrt.com>
 <20200725145728.10556-1-hdanton@sina.com>
 <2664182a-1d03-998d-8eff-8478174a310a@dd-wrt.com>
 <cb54c2746a3d4ce695e3bda8b576b40e@AcuMS.aculab.com>
Message-ID: <20200729013425.13740-1-hdanton@sina.com>


On Tue, 28 Jul 2020 22:29:02 +0530 Rakesh Pillai wrote:
> > -----Original Message-----
> > From: David Laight <David.Laight at ACULAB.COM>
> > Sent: Sunday, July 26, 2020 4:46 PM
> > To: 'Sebastian Gottschall' <s.gottschall at dd-wrt.com>; Hillf Danton
> > <hdanton at sina.com>
> > Cc: Andrew Lunn <andrew at lunn.ch>; Rakesh Pillai =
> <pillair at codeaurora.org>;
> > netdev at vger.kernel.org; linux-wireless at vger.kernel.org; linux-
> > kernel at vger.kernel.org; ath10k at lists.infradead.org;
> > dianders at chromium.org; Markus Elfring <Markus.Elfring at web.de>;
> > evgreen at chromium.org; kuba at kernel.org; johannes at sipsolutions.net;
> > davem at davemloft.net; kvalo at codeaurora.org
> > Subject: RE: [RFC 0/7] Add support to process rx packets in thread
> >=20
> > From: Sebastian Gottschall <s.gottschall at dd-wrt.com>
> > > Sent: 25 July 2020 16:42
> > > >> i agree. i just can say that i tested this patch recently due =
> this
> > > >> discussion here. and it can be changed by sysfs. but it doesnt =
> work for
> > > >> wifi drivers which are mainly using dummy netdev devices. for =
> this i
> > > >> made a small patch to get them working using napi_set_threaded
> > manually
> > > >> hardcoded in the drivers. (see patch bellow)
> >=20
> > > > By CONFIG_THREADED_NAPI, there is no need to consider what you did
> > here
> > > > in the napi core because device drivers know better and are =
> responsible
> > > > for it before calling napi_schedule(n).
> >=20
> > > yeah. but that approach will not work for some cases. some stupid
> > > drivers are using locking context in the napi poll function.
> > > in that case the performance will runto shit. i discovered this with =
> the
> > > mvneta eth driver (marvell) and mt76 tx polling (rx  works)
> > > for mvneta is will cause very high latencies and packet drops. for =
> mt76
> > > it causes packet stop. doesnt work simply (on all cases no crashes)
> > > so the threading will only work for drivers which are compatible =
> with
> > > that approach. it cannot be used as drop in replacement from my =
> point of
> > > view.
> > > its all a question of the driver design
> >=20
> > Why should it make (much) difference whether the napi callbacks (etc)
> > are done in the context of the interrupted process or that of a
> > specific kernel thread.
> > The process flags (or whatever) can even be set so that it appears
> > to be the expected 'softint' context.
> >=20
> > In any case running NAPI from a thread will just show up the next
> > piece of code that runs for ages in softint context.
> > I think I've seen the tail end of memory being freed under rcu
> > finally happening under softint and taking absolutely ages.
> >=20
> > 	David
> >=20
> 
> Hi All,
> 
> Is the threaded NAPI change posted to kernel ?

https://lore.kernel.org/netdev/20200726163119.86162-1-nbd at nbd.name/
https://lore.kernel.org/netdev/20200727123239.4921-1-nbd at nbd.name/

> Is the conclusion of this discussion that " we cannot use threads for
> processing packets " ??

That isn't it if any conclusion reached. Hard to answer your question
TBH, and OTOH I'm wondering in which context device driver developer
prefers to handle tx/rx, IRQ or BH or user context on available idle
CPUs, what is preventing them from doing that? Is it likely making
ant-antenna-size sense to set the napi::weight to 3 and turn to 30
kworkers for processing the ten-minute packet flood hitting the hardware
for instance on a system with 32 CPU cores or more?




From lkp at intel.com  Wed Jul 29 06:08:22 2020
From: lkp at intel.com (kernel test robot)
Date: Wed, 29 Jul 2020 18:08:22 +0800
Subject: [ath6kl:pending] BUILD SUCCESS
 3d9352e6b7bb95c174e390c73c7eecdafcc833c2
Message-ID: <5f214a96.k5kXf785zc4aJSmv%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git  pending
branch HEAD: 3d9352e6b7bb95c174e390c73c7eecdafcc833c2  ath5k: Replace HTTP links with HTTPS ones

elapsed time: 725m

configs tested: 69
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
arm                          prima2_defconfig
arm                      footbridge_defconfig
mips                        nlm_xlr_defconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
c6x                              allyesconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
parisc                           allyesconfig
s390                                defconfig
i386                             allyesconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
powerpc                             defconfig
i386                 randconfig-a003-20200728
i386                 randconfig-a004-20200728
i386                 randconfig-a005-20200728
i386                 randconfig-a002-20200728
i386                 randconfig-a006-20200728
i386                 randconfig-a001-20200728
x86_64               randconfig-a014-20200728
x86_64               randconfig-a012-20200728
x86_64               randconfig-a015-20200728
x86_64               randconfig-a016-20200728
x86_64               randconfig-a013-20200728
x86_64               randconfig-a011-20200728
i386                 randconfig-a016-20200728
i386                 randconfig-a012-20200728
i386                 randconfig-a013-20200728
i386                 randconfig-a014-20200728
i386                 randconfig-a011-20200728
i386                 randconfig-a015-20200728
riscv                            allyesconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                            allmodconfig
x86_64                                   rhel
x86_64                           allyesconfig
x86_64                    rhel-7.6-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                                  kexec

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Wed Jul 29 10:18:59 2020
From: lkp at intel.com (kernel test robot)
Date: Wed, 29 Jul 2020 22:18:59 +0800
Subject: [ath6kl:master-pending] BUILD SUCCESS
 6e47f7a4c304a65af9c5c83c88a44557214367f2
Message-ID: <5f218553.+NxGE7XcUqQlOB7K%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git  master-pending
branch HEAD: 6e47f7a4c304a65af9c5c83c88a44557214367f2  Merge branch 'pending' into master-pending

elapsed time: 976m

configs tested: 51
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

arm                              allyesconfig
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allmodconfig
arm                          prima2_defconfig
arm                      footbridge_defconfig
mips                        nlm_xlr_defconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
c6x                              allyesconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
parisc                           allyesconfig
s390                                defconfig
i386                             allyesconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                             defconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
riscv                            allyesconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                            allmodconfig
x86_64                                   rhel
x86_64                           allyesconfig
x86_64                    rhel-7.6-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                                  kexec

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From johannes at sipsolutions.net  Thu Jul 30 08:40:21 2020
From: johannes at sipsolutions.net (Johannes Berg)
Date: Thu, 30 Jul 2020 14:40:21 +0200
Subject: [RFC 1/7] mac80211: Add check for napi handle before WARN_ON
In-Reply-To: <000e01d66368$9a6ece70$cf4c6b50$@codeaurora.org>
References: <1595351666-28193-1-git-send-email-pillair@codeaurora.org>
 <1595351666-28193-2-git-send-email-pillair@codeaurora.org>
 <0dbdef912f9d61521011f638200fd451a3530568.camel@sipsolutions.net>
 <003201d6611e$c54a1c90$4fde55b0$@codeaurora.org>
 <ce380ea1fd1f5db40a92f67673f070a1f88eee50.camel@sipsolutions.net>
 <000e01d66368$9a6ece70$cf4c6b50$@codeaurora.org>
Message-ID: <446c9e45b5e904fa747c3d727a2c39ee904789e0.camel@sipsolutions.net>

On Sun, 2020-07-26 at 21:49 +0530, Rakesh Pillai wrote:

> We do have the usage of napi_gro_receive and netif_receive_skb in mac80211.
>                 /* deliver to local stack */
>                 if (rx->napi)
>                         napi_gro_receive(rx->napi, skb);
>                 else
>                         netif_receive_skb(skb);
> 
> 
> Also all the rx_handlers are called under the " rx->local->rx_path_lock" lock.
> Is the BH disable still required ?

I tend to think so, but you're welcome to show that it's not. The lock
serves a different purpose.

TBH, I don't have all of this in my head at all times either, so please
do your own work and analyse why it may or may not be necessary. But
without any such analysis I'm not going to take patches that change it.

johannes



From alsi at bang-olufsen.dk  Thu Jul 30 08:49:23 2020
From: alsi at bang-olufsen.dk (=?UTF-8?q?Alvin=20=C5=A0ipraga?=)
Date: Thu, 30 Jul 2020 14:49:23 +0200
Subject: [PATCH] Revert "ath: add support for special 0x0 regulatory domain"
Message-ID: <20200730124923.271429-1-alsi@bang-olufsen.dk>

This reverts commit 2dc016599cfa9672a147528ca26d70c3654a5423.

Per Atheros documentation to manufacturers, the EEPROM regulatory domain
code 0x0 must always map to "US". In particular, it should not map to a
custom world regulatory domain. For references, see [1] and [2] below.
Furthermore, __ath_regd_init() has a specific condition to set the
country code to "US" in this case, which emits the following log
message:

[    7.814307] ath: EEPROM indicates default country code should be used

The patch being reverted mistakenly maps 0x0 to the custom world
regulatory domain 0x64 - the most restrictive of the world regulatory
domains. The premise of the patch is that in the case of EEPROM
regulatory domain code 0x0, ath_is_world_regd() should return true. But,
as stated above, 0x0 should not map to a world regulatory domain, and so
the function should return false. The original behaviour, whereby
NL80211_REGDOM_SET_BY_COUNTRY_IE is ignored, was correct according to
the manufacturer's intent and should not have been changed.

[1] https://wireless.wiki.kernel.org/en/users/drivers/ath#the_0x0_regulatory_domain
[2] http://article.gmane.org/gmane.linux.kernel.wireless.general/38410

Fixes: 2dc016599cfa ("ath: add support for special 0x0 regulatory domain")
Cc: Wen Gong <wgong at codeaurora.org>
Cc: Luis R. Rodriguez <mcgrof at kernel.org>
Cc: linux-wireless at vger.kernel.org
Tested-on: QCA9880 hw2.0 PCI 10.2.4-1.0-00047
Signed-off-by: Alvin ?ipraga <alsi at bang-olufsen.dk>
---
 drivers/net/wireless/ath/regd.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/ath/regd.c b/drivers/net/wireless/ath/regd.c
index bee9110b91f3..20f4f8ea9f89 100644
--- a/drivers/net/wireless/ath/regd.c
+++ b/drivers/net/wireless/ath/regd.c
@@ -666,14 +666,14 @@ ath_regd_init_wiphy(struct ath_regulatory *reg,
 
 /*
  * Some users have reported their EEPROM programmed with
- * 0x8000 or 0x0 set, this is not a supported regulatory
- * domain but since we have more than one user with it we
- * need a solution for them. We default to 0x64, which is
- * the default Atheros world regulatory domain.
+ * 0x8000 set, this is not a supported regulatory domain
+ * but since we have more than one user with it we need
+ * a solution for them. We default to 0x64, which is the
+ * default Atheros world regulatory domain.
  */
 static void ath_regd_sanitize(struct ath_regulatory *reg)
 {
-	if (reg->current_rd != COUNTRY_ERD_FLAG && reg->current_rd != 0)
+	if (reg->current_rd != COUNTRY_ERD_FLAG)
 		return;
 	printk(KERN_DEBUG "ath: EEPROM regdomain sanitized\n");
 	reg->current_rd = 0x64;
-- 
2.27.0



From johannes at sipsolutions.net  Thu Jul 30 09:17:57 2020
From: johannes at sipsolutions.net (Johannes Berg)
Date: Thu, 30 Jul 2020 15:17:57 +0200
Subject: [PATCH 1/2] nl80211: vendor-cmd: qca: add dynamic SAR power limits
In-Reply-To: <CA+ASDXMf7iXuE9hQ-XitPPfvXP0EK5FchJLCu2+5Ag=ZC=0H0w@mail.gmail.com>
 (sfid-20200602_033247_740183_F75D1728)
References: <1576684108-30177-1-git-send-email-kvalo@codeaurora.org>
 <1576684108-30177-2-git-send-email-kvalo@codeaurora.org>
 <1576748692.7758.17.camel@realtek.com> <20191219154828.GA12287@w1.fi>
 <CA+ASDXMTYLGbEkBPHSqtyitMEvY5o_MjU0s+NoWdnN_ORy1gDw@mail.gmail.com>
 <20191219185522.GA16010@w1.fi>
 <CA+ASDXNOxkrZTxL0Jo4ONR2YtL83BVc_w-rBXc6ggBLdwUpDZw@mail.gmail.com>
 <871rpqly6a.fsf@kamboji.qca.qualcomm.com>
 <e8908eafd8e6050eef8782c6a7019e318d14f65f.camel@sipsolutions.net>
 <CA+ASDXMf7iXuE9hQ-XitPPfvXP0EK5FchJLCu2+5Ag=ZC=0H0w@mail.gmail.com>
 (sfid-20200602_033247_740183_F75D1728)
Message-ID: <b17c0e5ad80050df4da85653d413a71cfcc37629.camel@sipsolutions.net>

On Mon, 2020-06-01 at 18:32 -0700, Brian Norris wrote:
> I haven't quite reached the 3 month lag on the prior replies here :)

But I did, almost ;-)

> I do want to see this question resolved somehow, or else we'll be
> dragging along out-of-tree patches for...(counts on fingers)...4
> different nl80211 APIs for the same feature, and a driver-detecting
> user space for it.

Right.

> I think I was half-hoping that we'd get to chat at
> netdev about this, but that's not happening any time soon. (Topic for
> another day: does a "wireless workshop" still happen at a virtual-only
> conference?)

Yes, but only a short 1.5hr video call I guess. I'm not even sure what
to do there yet.

[snip]

Thanks for the overview!

> Also, Kalle had some concerns about stable ABI questions: shouldn't we
> bake in some kind of "check for support" feature to these kinds of
> APIs [3]? That would help ease transition, if we do start with a
> vendor API and move to a common one in the future. Given the nature of
> this feature, I wouldn't expect there will be a large variety of users
> making use of the APIs -- and I, for one, would be happy to migrate my
> user space over some period of time, as needed.

We do that? We list out the available vendor APIs, and in most cases
(perhaps not the one you've noticed there) we also list out the
availability of real nl80211 APIs in some way.

johannes



From johannes at sipsolutions.net  Thu Jul 30 09:24:11 2020
From: johannes at sipsolutions.net (Johannes Berg)
Date: Thu, 30 Jul 2020 15:24:11 +0200
Subject: [PATCH 1/2] nl80211: vendor-cmd: qca: add dynamic SAR power limits
In-Reply-To: <87y2n9clhj.fsf@codeaurora.org>
References: <1576684108-30177-1-git-send-email-kvalo@codeaurora.org>
 <1576684108-30177-2-git-send-email-kvalo@codeaurora.org>
 <1576748692.7758.17.camel@realtek.com> <20191219154828.GA12287@w1.fi>
 <CA+ASDXMTYLGbEkBPHSqtyitMEvY5o_MjU0s+NoWdnN_ORy1gDw@mail.gmail.com>
 <20191219185522.GA16010@w1.fi>
 <CA+ASDXNOxkrZTxL0Jo4ONR2YtL83BVc_w-rBXc6ggBLdwUpDZw@mail.gmail.com>
 <871rpqly6a.fsf@kamboji.qca.qualcomm.com>
 <e8908eafd8e6050eef8782c6a7019e318d14f65f.camel@sipsolutions.net>
 <CA+ASDXMf7iXuE9hQ-XitPPfvXP0EK5FchJLCu2+5Ag=ZC=0H0w@mail.gmail.com>
 <87lfjjx0o7.fsf@codeaurora.org>
 <CA+ASDXOAzPuOn_rMsRj4t56kC-TgoG0p5WhSTPJjB8xTTq5kfg@mail.gmail.com>
 <87y2n9clhj.fsf@codeaurora.org>
Message-ID: <c3ef60c2263a6840d21f6a797ad3ffb685a728b8.camel@sipsolutions.net>

On Fri, 2020-07-24 at 12:26 +0300, Kalle Valo wrote:

> > > So to me it feels like the best solution forward is to go with the
> > > vendor API, do you agree? We can, of course, later switch to the common
> > > API if we manage to create one which is usable for everyone.

But why wouldn't we try that now, while we have it all in our heads (in
a way ... even if this discussion drags out forever)?

I mean, the range-based approach ought to work, and if we define it as a
nested attribute list or so, we can even later add more attributes to it
(chain limits, whatnot) without any backward compatibility concerns.

So what is it that we _cannot_ do in a more common way today?

> > I think we've had some healthy (though very protracted) discussion,
> > and I don't think I've seen anyone bring up anything I wasn't already
> > aware of that would prevent eventual consolidation. As long as we
> > acknowledge those things (item 2 at
> > https://wireless.wiki.kernel.org/en/developers/documentation/nl80211#vendor-specific_api),
> > I'm happy.
> 
> Good, I was just checking that we all are on the same page.

But are we? ;-)

I don't really see anything in the new proposal [1] that really explains
why the common API that we've sort of vaguely outlined in this thread
couldn't work? It just speaks of technical difficulties ("need a
reporting API too"), but should we let that stop us?

[1] https://patchwork.kernel.org/patch/11686317/


johannes



From johannes at sipsolutions.net  Thu Jul 30 09:56:25 2020
From: johannes at sipsolutions.net (Johannes Berg)
Date: Thu, 30 Jul 2020 15:56:25 +0200
Subject: [RFC 1/2] devlink: add simple fw crash helpers
In-Reply-To: <20200525135746.45e764de@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
References: <20200519010530.GS11244@42.do-not-panic.com>
 <20200519211531.3702593-1-kuba@kernel.org>
 <20200522052046.GY11244@42.do-not-panic.com>
 <20200522101738.1495f4cc@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
 <2e5199edb433c217c7974ef7408ff8c7253145b6.camel@sipsolutions.net>
 <20200525135746.45e764de@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
Message-ID: <943c5eaf12bc9e92e817fb9818ebd65038f5fb54.camel@sipsolutions.net>

Hi,

Sorry ... long delay.

> > The reason I'm asking is that it's starting to sound like we really
> > ought to be implementing devlink, but we've got a bunch of
> > infrastructure that uses the devcoredump, and it'll take time
> > (significantly so) to change all that...
> 
> In devlink world pure FW core dumps are exposed by devlink regions.
> An API allowing reading device memory, registers, etc., but also 
> creating dumps of memory regions when things go wrong. It should be
> a fairly straightforward migration.

Right. We also have regions (various memory pieces, registers, ...).

One issue might be that for devlink we wouldn't want to expose these as
a single blob, I guess, but for devcoredump we already have a custom
format to glue all the things together. Since it seems unlikely that
anyone else would want to use the *iwlwifi* format to glue things
together, we'd have to do something there.

But perhaps that could be a matter of providing a "glue things into a
devcoredump" function that would have a reasonable default but could be
overridden by the driver for those migration cases.

> Devlink health is more targeted, the dump is supposed to contain only
> relevant information, selected and formatted by the driver. When device
> misbehaves driver reads the relevant registers and FW state and creates
> a formatted state dump. I believe each element of the dump must fit
> into a netlink message (but there may be multiple elements, see
> devlink_fmsg_prepare_skb()).

That wouldn't help for our big memory dumps, but OK.

> We should be able to convert dl-regions dumps and dl-health dumps into
> devcoredumps, but since health reporters are supposed to be more
> targeted there's usually multiple of them per device.

Right.

> Conversely devcoredumps can be trivially exposed as dl-region dumps,
> but I believe dl-health would require driver changes to format the
> information appropriately.

Agree.

Anyway, thanks. I'll put it on my list of things to look at ... not too
hopeful that will be soon, given how long it even took me to get back to
this email :)

johannes



From sm at mirdoraghi.ir  Thu Jul 30 14:19:49 2020
From: sm at mirdoraghi.ir (James kenneth)
Date: Thu, 30 Jul 2020 20:19:49 +0200
Subject: BUSINESS PROPOSAL
Message-ID: <mailman.1.1596147374.936.ath10k@lists.infradead.org>

Hello, 
     Apply for a loan, at a 3% interest rate.

    Do you need a personal loan?
    Do you need a business loan?
    Do you need a consolidation loan? 
    Do you need a secure loan?
    Do you need an unsecured loan?
    Do you need a mortgage loan?
    Do you need a pay off debt loan?
    Do you need a project loan?
    Do you need a student loan?
       
Whatever loan that you are looking for, kindly send us a mail:  (trustfinance1994 at outlook.com)

Mr. James kenneth
Managing Director

-- 
L'absence de virus dans ce courrier ?lectronique a ?t? v?rifi?e par le logiciel antivirus Avast.
https://www.avast.com/antivirus



From thomas at adapt-ip.com  Fri Jul 31 01:56:36 2020
From: thomas at adapt-ip.com (Thomas Pedersen)
Date: Thu, 30 Jul 2020 22:56:36 -0700
Subject: [PATCH mac80211-next] ath10k: fix unhandled switch value warning
Message-ID: <20200731055636.795173-1-thomas@adapt-ip.com>

Cited commit introduced the following warnings:

drivers/net/wireless/ath/ath10k/mac.c: In function 'chan_to_phymode':
drivers/net/wireless/ath/ath10k/mac.c:558:3: warning: enumeration value 'NL80211_CHAN_WIDTH_1' not handled in switch [-Wswitch]
  558 |   switch (chandef->width) {
      |   ^~~~~~
drivers/net/wireless/ath/ath10k/mac.c:558:3: warning: enumeration value 'NL80211_CHAN_WIDTH_2' not handled in switch [-Wswitch]
drivers/net/wireless/ath/ath10k/mac.c:558:3: warning: enumeration value 'NL80211_CHAN_WIDTH_4' not handled in switch [-Wswitch]
drivers/net/wireless/ath/ath10k/mac.c:558:3: warning: enumeration value 'NL80211_CHAN_WIDTH_8' not handled in switch [-Wswitch]
drivers/net/wireless/ath/ath10k/mac.c:558:3: warning: enumeration value 'NL80211_CHAN_WIDTH_16' not handled in switch [-Wswitch]
drivers/net/wireless/ath/ath10k/mac.c:581:3: warning: enumeration value 'NL80211_CHAN_WIDTH_1' not handled in switch [-Wswitch]
  581 |   switch (chandef->width) {
      |   ^~~~~~
drivers/net/wireless/ath/ath10k/mac.c:581:3: warning: enumeration value 'NL80211_CHAN_WIDTH_2' not handled in switch [-Wswitch]
drivers/net/wireless/ath/ath10k/mac.c:581:3: warning: enumeration value 'NL80211_CHAN_WIDTH_4' not handled in switch [-Wswitch]
drivers/net/wireless/ath/ath10k/mac.c:581:3: warning: enumeration value 'NL80211_CHAN_WIDTH_8' not handled in switch [-Wswitch]
drivers/net/wireless/ath/ath10k/mac.c:581:3: warning: enumeration value 'NL80211_CHAN_WIDTH_16' not handled in switch [-Wswitch]

Fix them by making the existing invalid channel width
cases the default, as the introduced channel widths
currently don't make sense in 2 or 5GHz either.

Fixes: e5cb3d34a66d ("nl80211: S1G band and channel definitions")
Signed-off-by: Thomas Pedersen <thomas at adapt-ip.com>
---
 drivers/net/wireless/ath/ath10k/mac.c | 9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 919d15584d4a..3c0c33a9f30c 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -568,11 +568,7 @@ chan_to_phymode(const struct cfg80211_chan_def *chandef)
 		case NL80211_CHAN_WIDTH_40:
 			phymode = MODE_11NG_HT40;
 			break;
-		case NL80211_CHAN_WIDTH_5:
-		case NL80211_CHAN_WIDTH_10:
-		case NL80211_CHAN_WIDTH_80:
-		case NL80211_CHAN_WIDTH_80P80:
-		case NL80211_CHAN_WIDTH_160:
+		default:
 			phymode = MODE_UNKNOWN;
 			break;
 		}
@@ -597,8 +593,7 @@ chan_to_phymode(const struct cfg80211_chan_def *chandef)
 		case NL80211_CHAN_WIDTH_80P80:
 			phymode = MODE_11AC_VHT80_80;
 			break;
-		case NL80211_CHAN_WIDTH_5:
-		case NL80211_CHAN_WIDTH_10:
+		default:
 			phymode = MODE_UNKNOWN;
 			break;
 		}
-- 
2.27.0



From murugana at codeaurora.org  Fri Jul 31 05:44:16 2020
From: murugana at codeaurora.org (Sathishkumar Muruganandam)
Date: Fri, 31 Jul 2020 15:14:16 +0530
Subject: [PATCH] ath10k: enable transmit data ack RSSI for QCA9884
Message-ID: <20200731094416.5172-1-murugana@codeaurora.org>

From: Abhishek Ambure <aambure at codeaurora.org>

commit cc78dc3b790619aa05f22a86a9152986bd73698c upstream.

This commit fixes the regression caused by
commit 6ddc3860a566 ("ath10k: add support for ack rssi value of data tx packets")
in linux-5.4.y branch.

ath10k_is_rssi_enable() always returns 0 for QCA9984 and this will cause
the ppdu_info_offset to hold invalid value in ath10k_htt_rx_tx_compl_ind().

This leads to CE corruption for HTC endpoints to cause WMI command failures
with insufficient HTC credits. Below warnings are seen due to beacon
command failure in QCA9984.

[  675.939638] ath10k_pci 0000:03:00.0: SWBA overrun on vdev 0, skipped old beacon
[  675.947828] ath10k_pci 0000:04:00.0: SWBA overrun on vdev 1, skipped old beacon

Tested HW: QCA9984
Tested FW: 10.4-3.10-00047
Tested Kernel version: 5.4.22

Fixes: 6ddc3860a566 ("ath10k: add support for ack rssi value of data tx packets")
Signed-off-by: Abhishek Ambure <aambure at codeaurora.org>
Signed-off-by: Balaji Pothunoori <bpothuno at codeaurora.org>
[kvalo at codeaurora.org: improve commit log]
Signed-off-by: Kalle Valo <kvalo at codeaurora.org>
Signed-off-by: Sathishkumar Muruganandam <murugana at codeaurora.org>
---
 drivers/net/wireless/ath/ath10k/hw.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/ath/ath10k/hw.c b/drivers/net/wireless/ath/ath10k/hw.c
index c415e971735b..004af89a02b8 100644
--- a/drivers/net/wireless/ath/ath10k/hw.c
+++ b/drivers/net/wireless/ath/ath10k/hw.c
@@ -1145,6 +1145,7 @@ static bool ath10k_qca99x0_rx_desc_msdu_limit_error(struct htt_rx_desc *rxd)
 const struct ath10k_hw_ops qca99x0_ops = {
 	.rx_desc_get_l3_pad_bytes = ath10k_qca99x0_rx_desc_get_l3_pad_bytes,
 	.rx_desc_get_msdu_limit_error = ath10k_qca99x0_rx_desc_msdu_limit_error,
+	.is_rssi_enable = ath10k_htt_tx_rssi_enable,
 };
 
 const struct ath10k_hw_ops qca6174_ops = {
-- 
2.17.1



From pillair at codeaurora.org  Fri Jul 31 14:27:20 2020
From: pillair at codeaurora.org (Rakesh Pillai)
Date: Fri, 31 Jul 2020 23:57:20 +0530
Subject: [PATCH v2 1/3] ath10k: Add history for tracking certain events
In-Reply-To: <1596220042-2778-1-git-send-email-pillair@codeaurora.org>
References: <1596220042-2778-1-git-send-email-pillair@codeaurora.org>
Message-ID: <1596220042-2778-2-git-send-email-pillair@codeaurora.org>

Add history for tracking the below events
- register read
- register write
- IRQ trigger
- NAPI poll
- CE service
- WMI cmd
- WMI event
- WMI tx completion

This will help in debugging any crash or any
improper behaviour.

Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.1-01040-QCAHLSWMTPLZ-1

Signed-off-by: Rakesh Pillai <pillair at codeaurora.org>
---
 drivers/net/wireless/ath/ath10k/ce.c      |   1 +
 drivers/net/wireless/ath/ath10k/core.h    |  74 +++++++++++++++++
 drivers/net/wireless/ath/ath10k/debug.c   | 133 ++++++++++++++++++++++++++++++
 drivers/net/wireless/ath/ath10k/debug.h   |  74 +++++++++++++++++
 drivers/net/wireless/ath/ath10k/snoc.c    |  15 +++-
 drivers/net/wireless/ath/ath10k/wmi-tlv.c |   1 +
 drivers/net/wireless/ath/ath10k/wmi.c     |  10 +++
 7 files changed, 307 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/ce.c b/drivers/net/wireless/ath/ath10k/ce.c
index 84ec80c..0f541de 100644
--- a/drivers/net/wireless/ath/ath10k/ce.c
+++ b/drivers/net/wireless/ath/ath10k/ce.c
@@ -1299,6 +1299,7 @@ void ath10k_ce_per_engine_service(struct ath10k *ar, unsigned int ce_id)
 	struct ath10k_hw_ce_host_wm_regs *wm_regs = ar->hw_ce_regs->wm_regs;
 	u32 ctrl_addr = ce_state->ctrl_addr;
 
+	ath10k_record_ce_event(ar, ATH10K_CE_SERVICE, ce_id);
 	/*
 	 * Clear before handling
 	 *
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 5c18f6c..46bd5aa 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -970,6 +970,75 @@ struct ath10k_bus_params {
 	bool hl_msdu_ids;
 };
 
+#define ATH10K_REG_ACCESS_HISTORY_MAX	512
+#define ATH10K_CE_EVENT_HISTORY_MAX	1024
+#define ATH10K_WMI_EVENT_HISTORY_MAX	512
+#define ATH10K_WMI_CMD_HISTORY_MAX	256
+
+#define ATH10K_WMI_DATA_LEN	16
+
+enum ath10k_ce_event {
+	ATH10K_IRQ_TRIGGER,
+	ATH10K_NAPI_POLL,
+	ATH10K_CE_SERVICE,
+	ATH10K_NAPI_COMPLETE,
+	ATH10K_NAPI_RESCHED,
+	ATH10K_IRQ_SUMMARY,
+};
+
+enum ath10k_wmi_type {
+	ATH10K_WMI_EVENT,
+	ATH10K_WMI_CMD,
+	ATH10K_WMI_TX_COMPL,
+};
+
+struct ath10k_reg_access_entry {
+	u32 cpu_id;
+	bool write;
+	u32 offset;
+	u32 val;
+	u64 timestamp;
+};
+
+struct ath10k_wmi_event_entry {
+	u32 cpu_id;
+	enum ath10k_wmi_type type;
+	u32 id;
+	u64 timestamp;
+	unsigned char data[ATH10K_WMI_DATA_LEN];
+};
+
+struct ath10k_ce_event_entry {
+	u32 cpu_id;
+	enum ath10k_ce_event event_type;
+	u32 ce_id;
+	u64 timestamp;
+};
+
+struct ath10k_wmi_event_history {
+	struct ath10k_wmi_event_entry *record;
+	u32 max_entries;
+	atomic_t index;
+	/* lock for accessing wmi event history */
+	spinlock_t hist_lock;
+};
+
+struct ath10k_ce_event_history {
+	struct ath10k_ce_event_entry *record;
+	u32 max_entries;
+	atomic_t index;
+	/* lock for accessing ce event history */
+	spinlock_t hist_lock;
+};
+
+struct ath10k_reg_access_history {
+	struct ath10k_reg_access_entry *record;
+	u32 max_entries;
+	atomic_t index;
+	/* lock for accessing register access history */
+	spinlock_t hist_lock;
+};
+
 struct ath10k {
 	struct ath_common ath_common;
 	struct ieee80211_hw *hw;
@@ -1261,6 +1330,11 @@ struct ath10k {
 	bool coex_support;
 	int coex_gpio_pin;
 
+	struct ath10k_reg_access_history reg_access_history;
+	struct ath10k_ce_event_history ce_event_history;
+	struct ath10k_wmi_event_history wmi_event_history;
+	struct ath10k_wmi_event_history wmi_cmd_history;
+
 	/* must be last */
 	u8 drv_priv[] __aligned(sizeof(void *));
 };
diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
index e8250a6..9105b0b 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -2722,4 +2722,137 @@ void ath10k_dbg_dump(struct ath10k *ar,
 }
 EXPORT_SYMBOL(ath10k_dbg_dump);
 
+int ath10k_core_reg_access_history_init(struct ath10k *ar, u32 max_entries)
+{
+	ar->reg_access_history.record = vzalloc(max_entries *
+						sizeof(struct ath10k_reg_access_entry));
+	if (!ar->reg_access_history.record)
+		return -ENOMEM;
+
+	ar->reg_access_history.max_entries = max_entries;
+	atomic_set(&ar->reg_access_history.index, 0);
+	spin_lock_init(&ar->reg_access_history.hist_lock);
+
+	return 0;
+}
+EXPORT_SYMBOL(ath10k_core_reg_access_history_init);
+
+int ath10k_core_wmi_cmd_history_init(struct ath10k *ar, u32 max_entries)
+{
+	ar->wmi_cmd_history.record = vzalloc(max_entries *
+					     sizeof(struct ath10k_wmi_event_entry));
+	if (!ar->wmi_cmd_history.record)
+		return -ENOMEM;
+
+	ar->wmi_cmd_history.max_entries = max_entries;
+	atomic_set(&ar->wmi_cmd_history.index, 0);
+	spin_lock_init(&ar->wmi_cmd_history.hist_lock);
+
+	return 0;
+}
+EXPORT_SYMBOL(ath10k_core_wmi_cmd_history_init);
+
+int ath10k_core_wmi_event_history_init(struct ath10k *ar, u32 max_entries)
+{
+	ar->wmi_event_history.record = vzalloc(max_entries *
+					       sizeof(struct ath10k_wmi_event_entry));
+	if (!ar->wmi_event_history.record)
+		return -ENOMEM;
+
+	ar->wmi_event_history.max_entries = max_entries;
+	atomic_set(&ar->wmi_event_history.index, 0);
+	spin_lock_init(&ar->wmi_event_history.hist_lock);
+
+	return 0;
+}
+EXPORT_SYMBOL(ath10k_core_wmi_event_history_init);
+
+int ath10k_core_ce_event_history_init(struct ath10k *ar, u32 max_entries)
+{
+	ar->ce_event_history.record = vzalloc(max_entries *
+					      sizeof(struct ath10k_ce_event_entry));
+	if (!ar->ce_event_history.record)
+		return -ENOMEM;
+
+	ar->ce_event_history.max_entries = max_entries;
+	atomic_set(&ar->ce_event_history.index, 0);
+	spin_lock_init(&ar->ce_event_history.hist_lock);
+
+	return 0;
+}
+EXPORT_SYMBOL(ath10k_core_ce_event_history_init);
+
+void ath10k_record_reg_access(struct ath10k *ar, u32 offset, u32 val, bool write)
+{
+	struct ath10k_reg_access_entry *entry;
+	u32 idx;
+
+	if (!ar->reg_access_history.record)
+		return;
+
+	idx = ath10k_core_get_next_idx(&ar->reg_access_history.index,
+				       ar->reg_access_history.max_entries);
+	entry = &ar->reg_access_history.record[idx];
+
+	entry->timestamp = ath10k_core_get_timestamp();
+	entry->write = write;
+	entry->offset = offset;
+	entry->val = val;
+}
+EXPORT_SYMBOL(ath10k_record_reg_access);
+
+void ath10k_record_wmi_event(struct ath10k *ar, enum ath10k_wmi_type type,
+			     u32 id, unsigned char *data)
+{
+	struct ath10k_wmi_event_entry *entry;
+	u32 idx;
+
+	if (type == ATH10K_WMI_EVENT) {
+		if (!ar->wmi_event_history.record)
+			return;
+
+		spin_lock_bh(&ar->wmi_event_history.hist_lock);
+		idx = ath10k_core_get_next_idx(&ar->reg_access_history.index,
+					       ar->wmi_event_history.max_entries);
+		spin_unlock_bh(&ar->wmi_event_history.hist_lock);
+		entry = &ar->wmi_event_history.record[idx];
+	} else {
+		if (!ar->wmi_cmd_history.record)
+			return;
+
+		spin_lock_bh(&ar->wmi_cmd_history.hist_lock);
+		idx = ath10k_core_get_next_idx(&ar->reg_access_history.index,
+					       ar->wmi_cmd_history.max_entries);
+		spin_unlock_bh(&ar->wmi_cmd_history.hist_lock);
+		entry = &ar->wmi_cmd_history.record[idx];
+	}
+
+	entry->timestamp = ath10k_core_get_timestamp();
+	entry->cpu_id = smp_processor_id();
+	entry->type = type;
+	entry->id = id;
+	memcpy(&entry->data, data + 4, ATH10K_WMI_DATA_LEN);
+}
+EXPORT_SYMBOL(ath10k_record_wmi_event);
+
+void ath10k_record_ce_event(struct ath10k *ar, enum ath10k_ce_event event_type,
+			    int ce_id)
+{
+	struct ath10k_ce_event_entry *entry;
+	u32 idx;
+
+	if (!ar->ce_event_history.record)
+		return;
+
+	idx = ath10k_core_get_next_idx(&ar->ce_event_history.index,
+				       ar->ce_event_history.max_entries);
+	entry = &ar->ce_event_history.record[idx];
+
+	entry->timestamp = ath10k_core_get_timestamp();
+	entry->cpu_id = smp_processor_id();
+	entry->event_type = event_type;
+	entry->ce_id = ce_id;
+}
+EXPORT_SYMBOL(ath10k_record_ce_event);
+
 #endif /* CONFIG_ATH10K_DEBUG */
diff --git a/drivers/net/wireless/ath/ath10k/debug.h b/drivers/net/wireless/ath/ath10k/debug.h
index 997c1c8..c28aeb1 100644
--- a/drivers/net/wireless/ath/ath10k/debug.h
+++ b/drivers/net/wireless/ath/ath10k/debug.h
@@ -258,6 +258,38 @@ void ath10k_dbg_dump(struct ath10k *ar,
 		     enum ath10k_debug_mask mask,
 		     const char *msg, const char *prefix,
 		     const void *buf, size_t len);
+
+/* ========== History init APIs =========== */
+int ath10k_core_reg_access_history_init(struct ath10k *ar, u32 max_entries);
+int ath10k_core_wmi_cmd_history_init(struct ath10k *ar, u32 max_entries);
+int ath10k_core_wmi_event_history_init(struct ath10k *ar, u32 max_entries);
+int ath10k_core_ce_event_history_init(struct ath10k *ar, u32 max_entries);
+
+/* ========== History record APIs =========== */
+void ath10k_record_reg_access(struct ath10k *ar, u32 offset, u32 val,
+			      bool write);
+void ath10k_record_wmi_event(struct ath10k *ar, enum ath10k_wmi_type type,
+			     u32 id, unsigned char *data);
+void ath10k_record_ce_event(struct ath10k *ar,
+			    enum ath10k_ce_event event_type,
+			    int ce_id);
+
+static inline u64 ath10k_core_get_timestamp(void)
+{
+	struct timespec64 ts;
+
+	ktime_get_real_ts64(&ts);
+	return ((u64)ts.tv_sec * 1000000) + (ts.tv_nsec / 1000);
+}
+
+static inline int ath10k_core_get_next_idx(atomic_t *index, u32 max_entries)
+{
+	u32 curr_idx;
+
+	curr_idx = atomic_fetch_inc(index);
+	return (curr_idx & (max_entries - 1));
+}
+
 #else /* CONFIG_ATH10K_DEBUG */
 
 static inline int __ath10k_dbg(struct ath10k *ar,
@@ -273,6 +305,48 @@ static inline void ath10k_dbg_dump(struct ath10k *ar,
 				   const void *buf, size_t len)
 {
 }
+
+static inline int ath10k_core_reg_access_history_init(struct ath10k *ar,
+						      u32 max_entries)
+{
+	return 0;
+}
+
+static inline int ath10k_core_wmi_cmd_history_init(struct ath10k *ar,
+						   u32 max_entries)
+{
+	return 0;
+}
+
+static inline int ath10k_core_wmi_event_history_init(struct ath10k *ar,
+						     u32 max_entries)
+{
+	return 0;
+}
+
+static inline int ath10k_core_ce_event_history_init(struct ath10k *ar,
+						    u32 max_entries)
+{
+	return 0;
+}
+
+static inline void ath10k_record_reg_access(struct ath10k *ar, u32 offset,
+					    u32 val, bool write)
+{
+}
+
+static inline void ath10k_record_wmi_event(struct ath10k *ar,
+					   enum ath10k_wmi_type type,
+					   u32 id, unsigned char *data)
+{
+}
+
+static inline void ath10k_record_ce_event(struct ath10k *ar,
+					  enum ath10k_ce_event event_type,
+					  int ce_id)
+{
+}
+
 #endif /* CONFIG_ATH10K_DEBUG */
 
 /* Avoid calling __ath10k_dbg() if debug_mask is not set and tracing
diff --git a/drivers/net/wireless/ath/ath10k/snoc.c b/drivers/net/wireless/ath/ath10k/snoc.c
index 1ef5fdb..aa7ee32 100644
--- a/drivers/net/wireless/ath/ath10k/snoc.c
+++ b/drivers/net/wireless/ath/ath10k/snoc.c
@@ -473,6 +473,7 @@ static void ath10k_snoc_write32(struct ath10k *ar, u32 offset, u32 value)
 {
 	struct ath10k_snoc *ar_snoc = ath10k_snoc_priv(ar);
 
+	ath10k_record_reg_access(ar, offset, value, true);
 	iowrite32(value, ar_snoc->mem + offset);
 }
 
@@ -482,6 +483,7 @@ static u32 ath10k_snoc_read32(struct ath10k *ar, u32 offset)
 	u32 val;
 
 	val = ioread32(ar_snoc->mem + offset);
+	ath10k_record_reg_access(ar, offset, val, false);
 
 	return val;
 }
@@ -1159,6 +1161,7 @@ static irqreturn_t ath10k_snoc_per_engine_handler(int irq, void *arg)
 			    ce_id);
 		return IRQ_HANDLED;
 	}
+	ath10k_record_ce_event(ar, ATH10K_IRQ_TRIGGER, ce_id);
 
 	ath10k_ce_disable_interrupt(ar, ce_id);
 	set_bit(ce_id, ar_snoc->pending_ce_irqs);
@@ -1175,6 +1178,7 @@ static int ath10k_snoc_napi_poll(struct napi_struct *ctx, int budget)
 	int done = 0;
 	int ce_id;
 
+	ath10k_record_ce_event(ar, ATH10K_NAPI_POLL, 0);
 	if (test_bit(ATH10K_FLAG_CRASH_FLUSH, &ar->dev_flags)) {
 		napi_complete(ctx);
 		return done;
@@ -1188,8 +1192,12 @@ static int ath10k_snoc_napi_poll(struct napi_struct *ctx, int budget)
 
 	done = ath10k_htt_txrx_compl_task(ar, budget);
 
-	if (done < budget)
+	if (done < budget) {
 		napi_complete(ctx);
+		ath10k_record_ce_event(ar, ATH10K_NAPI_COMPLETE, 0);
+	} else {
+		ath10k_record_ce_event(ar, ATH10K_NAPI_RESCHED, 0);
+	}
 
 	return done;
 }
@@ -1660,6 +1668,11 @@ static int ath10k_snoc_probe(struct platform_device *pdev)
 	ar->ce_priv = &ar_snoc->ce;
 	msa_size = drv_data->msa_size;
 
+	ath10k_core_reg_access_history_init(ar, ATH10K_REG_ACCESS_HISTORY_MAX);
+	ath10k_core_wmi_event_history_init(ar, ATH10K_WMI_EVENT_HISTORY_MAX);
+	ath10k_core_wmi_cmd_history_init(ar, ATH10K_WMI_CMD_HISTORY_MAX);
+	ath10k_core_ce_event_history_init(ar, ATH10K_CE_EVENT_HISTORY_MAX);
+
 	ath10k_snoc_quirks_init(ar);
 
 	ret = ath10k_snoc_resource_init(ar);
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
index 932266d..9df5748 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
@@ -627,6 +627,7 @@ static void ath10k_wmi_tlv_op_rx(struct ath10k *ar, struct sk_buff *skb)
 	if (skb_pull(skb, sizeof(struct wmi_cmd_hdr)) == NULL)
 		goto out;
 
+	ath10k_record_wmi_event(ar, ATH10K_WMI_EVENT, id, skb->data);
 	trace_ath10k_wmi_event(ar, id, skb->data, skb->len);
 
 	consumed = ath10k_tm_event_wmi(ar, id, skb);
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index a81a1ab..8ebd05c 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -1802,6 +1802,15 @@ struct sk_buff *ath10k_wmi_alloc_skb(struct ath10k *ar, u32 len)
 
 static void ath10k_wmi_htc_tx_complete(struct ath10k *ar, struct sk_buff *skb)
 {
+	struct wmi_cmd_hdr *cmd_hdr;
+	enum wmi_tlv_event_id id;
+
+	cmd_hdr = (struct wmi_cmd_hdr *)skb->data;
+	id = MS(__le32_to_cpu(cmd_hdr->cmd_id), WMI_CMD_HDR_CMD_ID);
+
+	ath10k_record_wmi_event(ar, ATH10K_WMI_TX_COMPL, id,
+				skb->data + sizeof(struct wmi_cmd_hdr));
+
 	dev_kfree_skb(skb);
 }
 
@@ -1912,6 +1921,7 @@ int ath10k_wmi_cmd_send(struct ath10k *ar, struct sk_buff *skb, u32 cmd_id)
 
 	might_sleep();
 
+	ath10k_record_wmi_event(ar, ATH10K_WMI_CMD, cmd_id, skb->data);
 	if (cmd_id == WMI_CMD_UNSUPPORTED) {
 		ath10k_warn(ar, "wmi command %d is not supported by firmware\n",
 			    cmd_id);
-- 
2.7.4



From pillair at codeaurora.org  Fri Jul 31 14:27:21 2020
From: pillair at codeaurora.org (Rakesh Pillai)
Date: Fri, 31 Jul 2020 23:57:21 +0530
Subject: [PATCH v2 2/3] ath10k: Add module param to enable history
In-Reply-To: <1596220042-2778-1-git-send-email-pillair@codeaurora.org>
References: <1596220042-2778-1-git-send-email-pillair@codeaurora.org>
Message-ID: <1596220042-2778-3-git-send-email-pillair@codeaurora.org>

Add a module param to enable recording history
of certain debug events. This module parameter
is a mask of the different history recording to
be enabled.

The memory for recording the history will not be
allocated if its not enabled via module parameter.
This is to avoid unnecessary memory allocation when
recording the history is not needed.

To enable all the history recording, the driver
should be loaded as below
"insmod ath10k_core.ko history_enable_mask=0xf"

Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.1-01040-QCAHLSWMTPLZ-1

Signed-off-by: Rakesh Pillai <pillair at codeaurora.org>
---
 drivers/net/wireless/ath/ath10k/core.c  |  3 +++
 drivers/net/wireless/ath/ath10k/core.h  |  8 ++++++++
 drivers/net/wireless/ath/ath10k/debug.c | 26 ++++++++++++++++++++++----
 drivers/net/wireless/ath/ath10k/debug.h |  1 +
 4 files changed, 34 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 9104496..f91a9d0 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -29,6 +29,7 @@
 unsigned int ath10k_debug_mask;
 EXPORT_SYMBOL(ath10k_debug_mask);
 
+unsigned long ath10k_history_enable_mask;
 static unsigned int ath10k_cryptmode_param;
 static bool uart_print;
 static bool skip_otp;
@@ -46,6 +47,7 @@ module_param(skip_otp, bool, 0644);
 module_param(rawmode, bool, 0644);
 module_param(fw_diag_log, bool, 0644);
 module_param_named(coredump_mask, ath10k_coredump_mask, ulong, 0444);
+module_param_named(history_enable_mask, ath10k_history_enable_mask, ulong, 0444);
 
 MODULE_PARM_DESC(debug_mask, "Debugging mask");
 MODULE_PARM_DESC(uart_print, "Uart target debugging");
@@ -54,6 +56,7 @@ MODULE_PARM_DESC(cryptmode, "Crypto mode: 0-hardware, 1-software");
 MODULE_PARM_DESC(rawmode, "Use raw 802.11 frame datapath");
 MODULE_PARM_DESC(coredump_mask, "Bitfield of what to include in firmware crash file");
 MODULE_PARM_DESC(fw_diag_log, "Diag based fw log debugging");
+MODULE_PARM_DESC(history_enable_mask, "Enable events history recording");
 
 static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 	{
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 46bd5aa..ce429df 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -977,6 +977,14 @@ struct ath10k_bus_params {
 
 #define ATH10K_WMI_DATA_LEN	16
 
+enum ath10k_history {
+	ATH10K_REG_ACCESS_HISTORY,
+	ATH10K_CE_EVENTS_HISTORY,
+	ATH10K_WMI_CMD_HISTORY,
+	ATH10K_WMI_EVENTS_HISTORY,
+	ATH10K_HISTORY_MAX,
+};
+
 enum ath10k_ce_event {
 	ATH10K_IRQ_TRIGGER,
 	ATH10K_NAPI_POLL,
diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
index 9105b0b..5d08652 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -2724,6 +2724,9 @@ EXPORT_SYMBOL(ath10k_dbg_dump);
 
 int ath10k_core_reg_access_history_init(struct ath10k *ar, u32 max_entries)
 {
+	if (!test_bit(ATH10K_REG_ACCESS_HISTORY, &ath10k_history_enable_mask))
+		return 0;
+
 	ar->reg_access_history.record = vzalloc(max_entries *
 						sizeof(struct ath10k_reg_access_entry));
 	if (!ar->reg_access_history.record)
@@ -2739,6 +2742,9 @@ EXPORT_SYMBOL(ath10k_core_reg_access_history_init);
 
 int ath10k_core_wmi_cmd_history_init(struct ath10k *ar, u32 max_entries)
 {
+	if (!test_bit(ATH10K_WMI_CMD_HISTORY, &ath10k_history_enable_mask))
+		return 0;
+
 	ar->wmi_cmd_history.record = vzalloc(max_entries *
 					     sizeof(struct ath10k_wmi_event_entry));
 	if (!ar->wmi_cmd_history.record)
@@ -2754,6 +2760,9 @@ EXPORT_SYMBOL(ath10k_core_wmi_cmd_history_init);
 
 int ath10k_core_wmi_event_history_init(struct ath10k *ar, u32 max_entries)
 {
+	if (!test_bit(ATH10K_WMI_EVENTS_HISTORY, &ath10k_history_enable_mask))
+		return 0;
+
 	ar->wmi_event_history.record = vzalloc(max_entries *
 					       sizeof(struct ath10k_wmi_event_entry));
 	if (!ar->wmi_event_history.record)
@@ -2769,6 +2778,9 @@ EXPORT_SYMBOL(ath10k_core_wmi_event_history_init);
 
 int ath10k_core_ce_event_history_init(struct ath10k *ar, u32 max_entries)
 {
+	if (!test_bit(ATH10K_CE_EVENTS_HISTORY, &ath10k_history_enable_mask))
+		return 0;
+
 	ar->ce_event_history.record = vzalloc(max_entries *
 					      sizeof(struct ath10k_ce_event_entry));
 	if (!ar->ce_event_history.record)
@@ -2787,7 +2799,8 @@ void ath10k_record_reg_access(struct ath10k *ar, u32 offset, u32 val, bool write
 	struct ath10k_reg_access_entry *entry;
 	u32 idx;
 
-	if (!ar->reg_access_history.record)
+	if (!test_bit(ATH10K_REG_ACCESS_HISTORY, &ath10k_history_enable_mask) ||
+	    !ar->reg_access_history.record)
 		return;
 
 	idx = ath10k_core_get_next_idx(&ar->reg_access_history.index,
@@ -2808,7 +2821,9 @@ void ath10k_record_wmi_event(struct ath10k *ar, enum ath10k_wmi_type type,
 	u32 idx;
 
 	if (type == ATH10K_WMI_EVENT) {
-		if (!ar->wmi_event_history.record)
+		if (!test_bit(ATH10K_WMI_EVENTS_HISTORY,
+			      &ath10k_history_enable_mask) ||
+		    !ar->wmi_event_history.record)
 			return;
 
 		spin_lock_bh(&ar->wmi_event_history.hist_lock);
@@ -2817,7 +2832,9 @@ void ath10k_record_wmi_event(struct ath10k *ar, enum ath10k_wmi_type type,
 		spin_unlock_bh(&ar->wmi_event_history.hist_lock);
 		entry = &ar->wmi_event_history.record[idx];
 	} else {
-		if (!ar->wmi_cmd_history.record)
+		if (!test_bit(ATH10K_WMI_CMD_HISTORY,
+			      &ath10k_history_enable_mask) ||
+		    !ar->wmi_event_history.record)
 			return;
 
 		spin_lock_bh(&ar->wmi_cmd_history.hist_lock);
@@ -2841,7 +2858,8 @@ void ath10k_record_ce_event(struct ath10k *ar, enum ath10k_ce_event event_type,
 	struct ath10k_ce_event_entry *entry;
 	u32 idx;
 
-	if (!ar->ce_event_history.record)
+	if (!test_bit(ATH10K_CE_EVENTS_HISTORY, &ath10k_history_enable_mask) ||
+	    !ar->ce_event_history.record)
 		return;
 
 	idx = ath10k_core_get_next_idx(&ar->ce_event_history.index,
diff --git a/drivers/net/wireless/ath/ath10k/debug.h b/drivers/net/wireless/ath/ath10k/debug.h
index c28aeb1..7799b89 100644
--- a/drivers/net/wireless/ath/ath10k/debug.h
+++ b/drivers/net/wireless/ath/ath10k/debug.h
@@ -75,6 +75,7 @@ struct ath10k_pktlog_hdr {
 #define ATH10K_TX_POWER_MIN_VAL 0
 
 extern unsigned int ath10k_debug_mask;
+extern unsigned long ath10k_history_enable_mask;
 
 __printf(2, 3) void ath10k_info(struct ath10k *ar, const char *fmt, ...);
 __printf(2, 3) void ath10k_err(struct ath10k *ar, const char *fmt, ...);
-- 
2.7.4



From pillair at codeaurora.org  Fri Jul 31 14:27:19 2020
From: pillair at codeaurora.org (Rakesh Pillai)
Date: Fri, 31 Jul 2020 23:57:19 +0530
Subject: [PATCH v2 0/3] 
Message-ID: <1596220042-2778-1-git-send-email-pillair@codeaurora.org>

The history recording will be compiled only if
ATH10K_DEBUG is enabled, and also enabled via
the module parameter. Once the history recording
is enabled via module parameter, it can be enabled
or disabled runtime via debugfs.

---
Changes from v1:
- Add module param and debugfs to enable/disable history recording.

Rakesh Pillai (3):
  ath10k: Add history for tracking certain events
  ath10k: Add module param to enable history
  ath10k: Add debugfs support to enable event history

 drivers/net/wireless/ath/ath10k/ce.c      |   1 +
 drivers/net/wireless/ath/ath10k/core.c    |   3 +
 drivers/net/wireless/ath/ath10k/core.h    |  82 ++++++++++++
 drivers/net/wireless/ath/ath10k/debug.c   | 207 ++++++++++++++++++++++++++++++
 drivers/net/wireless/ath/ath10k/debug.h   |  75 +++++++++++
 drivers/net/wireless/ath/ath10k/snoc.c    |  15 ++-
 drivers/net/wireless/ath/ath10k/wmi-tlv.c |   1 +
 drivers/net/wireless/ath/ath10k/wmi.c     |  10 ++
 8 files changed, 393 insertions(+), 1 deletion(-)

-- 
2.7.4



From pillair at codeaurora.org  Fri Jul 31 14:27:22 2020
From: pillair at codeaurora.org (Rakesh Pillai)
Date: Fri, 31 Jul 2020 23:57:22 +0530
Subject: [PATCH v2 3/3] ath10k: Add debugfs support to enable event history
In-Reply-To: <1596220042-2778-1-git-send-email-pillair@codeaurora.org>
References: <1596220042-2778-1-git-send-email-pillair@codeaurora.org>
Message-ID: <1596220042-2778-4-git-send-email-pillair@codeaurora.org>

Add the support to enable/disable the recording of
debug events history.

The enable/disable of the history from debugfs will
not make any affect if its not enabled via module
parameter.

Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.1-01040-QCAHLSWMTPLZ-1

Signed-off-by: Rakesh Pillai <pillair at codeaurora.org>
---
 drivers/net/wireless/ath/ath10k/debug.c | 56 +++++++++++++++++++++++++++++++++
 1 file changed, 56 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
index 5d08652..6785fae 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -610,6 +610,59 @@ static const struct file_operations fops_simulate_fw_crash = {
 	.llseek = default_llseek,
 };
 
+static ssize_t ath10k_read_history_enable(struct file *file,
+					  char __user *user_buf,
+					  size_t count, loff_t *ppos)
+{
+	const char buf[] =
+		"To enable recording of certain event history, write to this file with the enable mask\n"
+		"BIT(0): Enable Reg Access history\n"
+		"	- Register write events\n"
+		"	- Register read events\n"
+		"BIT(1): Enable CE events history\n"
+		"	- ATH10K_IRQ_TRIGGER event\n"
+		"	- ATH10K_NAPI_POLL event\n"
+		"	- ATH10K_CE_SERVICE event\n"
+		"	- ATH10K_NAPI_COMPLETE event\n"
+		"	- ATH10K_NAPI_RESCHED event\n"
+		"	- ATH10K_IRQ_SUMMARY event\n"
+		"BIT(2): Enable WMI CMD history\n"
+		"	- WMI CMD event\n"
+		"	- WMI CMD TX completion event\n"
+		"BIT(3): Enable WMI events history\n"
+		"	- WMI Events event\n";
+
+	return simple_read_from_buffer(user_buf, count, ppos, buf, strlen(buf));
+}
+
+static ssize_t ath10k_write_history_enable(struct file *file,
+					   const char __user *user_buf,
+					   size_t count, loff_t *ppos)
+{
+	u32 history_enable_mask;
+	int i, ret;
+
+	ret = kstrtou32_from_user(user_buf, count, 0, &history_enable_mask);
+	if (ret)
+		return ret;
+
+	for (i = 0; i < ATH10K_HISTORY_MAX; i++)
+		if (history_enable_mask & BIT(i))
+			set_bit(i, &ath10k_history_enable_mask);
+		else
+			clear_bit(i, &ath10k_history_enable_mask);
+
+	return count;
+}
+
+static const struct file_operations fops_history_enable = {
+	.read = ath10k_read_history_enable,
+	.write = ath10k_write_history_enable,
+	.open = simple_open,
+	.owner = THIS_MODULE,
+	.llseek = default_llseek,
+};
+
 static ssize_t ath10k_read_chip_id(struct file *file, char __user *user_buf,
 				   size_t count, loff_t *ppos)
 {
@@ -2658,6 +2711,9 @@ int ath10k_debug_register(struct ath10k *ar)
 	debugfs_create_file("reset_htt_stats", 0200, ar->debug.debugfs_phy, ar,
 			    &fops_reset_htt_stats);
 
+	debugfs_create_file("history_enable", 0644, ar->debug.debugfs_phy, ar,
+			    &fops_history_enable);
+
 	return 0;
 }
 
-- 
2.7.4



From greearb at candelatech.com  Fri Jul 31 14:38:15 2020
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 31 Jul 2020 11:38:15 -0700
Subject: [PATCH v2 1/3] ath10k: Add history for tracking certain events
In-Reply-To: <1596220042-2778-2-git-send-email-pillair@codeaurora.org>
References: <1596220042-2778-1-git-send-email-pillair@codeaurora.org>
 <1596220042-2778-2-git-send-email-pillair@codeaurora.org>
Message-ID: <bedc5fe0-1904-d045-4a84-0869ee1b0b2e@candelatech.com>

On 7/31/20 11:27 AM, Rakesh Pillai wrote:
> Add history for tracking the below events
> - register read
> - register write
> - IRQ trigger
> - NAPI poll
> - CE service
> - WMI cmd
> - WMI event
> - WMI tx completion
> 
> This will help in debugging any crash or any
> improper behaviour.
> 
> Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.1-01040-QCAHLSWMTPLZ-1
> 
> Signed-off-by: Rakesh Pillai <pillair at codeaurora.org>
> ---
>   drivers/net/wireless/ath/ath10k/ce.c      |   1 +
>   drivers/net/wireless/ath/ath10k/core.h    |  74 +++++++++++++++++
>   drivers/net/wireless/ath/ath10k/debug.c   | 133 ++++++++++++++++++++++++++++++
>   drivers/net/wireless/ath/ath10k/debug.h   |  74 +++++++++++++++++
>   drivers/net/wireless/ath/ath10k/snoc.c    |  15 +++-
>   drivers/net/wireless/ath/ath10k/wmi-tlv.c |   1 +
>   drivers/net/wireless/ath/ath10k/wmi.c     |  10 +++
>   7 files changed, 307 insertions(+), 1 deletion(-)
> 

> +void ath10k_record_wmi_event(struct ath10k *ar, enum ath10k_wmi_type type,
> +			     u32 id, unsigned char *data)
> +{
> +	struct ath10k_wmi_event_entry *entry;
> +	u32 idx;
> +
> +	if (type == ATH10K_WMI_EVENT) {
> +		if (!ar->wmi_event_history.record)
> +			return;

This check above is duplicated below, add it once at top of the method
instead.

> +
> +		spin_lock_bh(&ar->wmi_event_history.hist_lock);
> +		idx = ath10k_core_get_next_idx(&ar->reg_access_history.index,
> +					       ar->wmi_event_history.max_entries);
> +		spin_unlock_bh(&ar->wmi_event_history.hist_lock);
> +		entry = &ar->wmi_event_history.record[idx];
> +	} else {
> +		if (!ar->wmi_cmd_history.record)
> +			return;
> +
> +		spin_lock_bh(&ar->wmi_cmd_history.hist_lock);
> +		idx = ath10k_core_get_next_idx(&ar->reg_access_history.index,
> +					       ar->wmi_cmd_history.max_entries);
> +		spin_unlock_bh(&ar->wmi_cmd_history.hist_lock);
> +		entry = &ar->wmi_cmd_history.record[idx];
> +	}
> +
> +	entry->timestamp = ath10k_core_get_timestamp();
> +	entry->cpu_id = smp_processor_id();
> +	entry->type = type;
> +	entry->id = id;
> +	memcpy(&entry->data, data + 4, ATH10K_WMI_DATA_LEN);
> +}
> +EXPORT_SYMBOL(ath10k_record_wmi_event);

> @@ -1660,6 +1668,11 @@ static int ath10k_snoc_probe(struct platform_device *pdev)
>   	ar->ce_priv = &ar_snoc->ce;
>   	msa_size = drv_data->msa_size;
>   
> +	ath10k_core_reg_access_history_init(ar, ATH10K_REG_ACCESS_HISTORY_MAX);
> +	ath10k_core_wmi_event_history_init(ar, ATH10K_WMI_EVENT_HISTORY_MAX);
> +	ath10k_core_wmi_cmd_history_init(ar, ATH10K_WMI_CMD_HISTORY_MAX);
> +	ath10k_core_ce_event_history_init(ar, ATH10K_CE_EVENT_HISTORY_MAX);

Maybe only enable this once user turns it on?  It sucks up a bit of memory?

> +
>   	ath10k_snoc_quirks_init(ar);
>   
>   	ret = ath10k_snoc_resource_init(ar);
> diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
> index 932266d..9df5748 100644
> --- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
> +++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
> @@ -627,6 +627,7 @@ static void ath10k_wmi_tlv_op_rx(struct ath10k *ar, struct sk_buff *skb)
>   	if (skb_pull(skb, sizeof(struct wmi_cmd_hdr)) == NULL)
>   		goto out;
>   
> +	ath10k_record_wmi_event(ar, ATH10K_WMI_EVENT, id, skb->data);
>   	trace_ath10k_wmi_event(ar, id, skb->data, skb->len);
>   
>   	consumed = ath10k_tm_event_wmi(ar, id, skb);
> diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
> index a81a1ab..8ebd05c 100644
> --- a/drivers/net/wireless/ath/ath10k/wmi.c
> +++ b/drivers/net/wireless/ath/ath10k/wmi.c
> @@ -1802,6 +1802,15 @@ struct sk_buff *ath10k_wmi_alloc_skb(struct ath10k *ar, u32 len)
>   
>   static void ath10k_wmi_htc_tx_complete(struct ath10k *ar, struct sk_buff *skb)
>   {
> +	struct wmi_cmd_hdr *cmd_hdr;
> +	enum wmi_tlv_event_id id;
> +
> +	cmd_hdr = (struct wmi_cmd_hdr *)skb->data;
> +	id = MS(__le32_to_cpu(cmd_hdr->cmd_id), WMI_CMD_HDR_CMD_ID);
> +
> +	ath10k_record_wmi_event(ar, ATH10K_WMI_TX_COMPL, id,
> +				skb->data + sizeof(struct wmi_cmd_hdr));
> +
>   	dev_kfree_skb(skb);
>   }

I think guard the above new code with if (unlikely(ar->ce_event_history.record)) { ... }

All in all, I think I'd want to compile this out (while leaving other debug compiled
in) since it seems this stuff would be rarely used and it adds method calls to hot
paths.

That is a decision for Kalle though, so see what he says...

Thanks,
Ben


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


From f.fainelli at gmail.com  Fri Jul 31 14:46:31 2020
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Fri, 31 Jul 2020 11:46:31 -0700
Subject: [PATCH v2 0/3]
In-Reply-To: <1596220042-2778-1-git-send-email-pillair@codeaurora.org>
References: <1596220042-2778-1-git-send-email-pillair@codeaurora.org>
Message-ID: <c6c5b3c5-f862-9cee-6863-24f666cc28f5@gmail.com>

On 7/31/20 11:27 AM, Rakesh Pillai wrote:
> The history recording will be compiled only if
> ATH10K_DEBUG is enabled, and also enabled via
> the module parameter. Once the history recording
> is enabled via module parameter, it can be enabled
> or disabled runtime via debugfs.

Why not use trace prints and retrieving them via the function tracer?
This seems very ad-hoc.

> 
> ---
> Changes from v1:
> - Add module param and debugfs to enable/disable history recording.
> 
> Rakesh Pillai (3):
>   ath10k: Add history for tracking certain events
>   ath10k: Add module param to enable history
>   ath10k: Add debugfs support to enable event history
> 
>  drivers/net/wireless/ath/ath10k/ce.c      |   1 +
>  drivers/net/wireless/ath/ath10k/core.c    |   3 +
>  drivers/net/wireless/ath/ath10k/core.h    |  82 ++++++++++++
>  drivers/net/wireless/ath/ath10k/debug.c   | 207 ++++++++++++++++++++++++++++++
>  drivers/net/wireless/ath/ath10k/debug.h   |  75 +++++++++++
>  drivers/net/wireless/ath/ath10k/snoc.c    |  15 ++-
>  drivers/net/wireless/ath/ath10k/wmi-tlv.c |   1 +
>  drivers/net/wireless/ath/ath10k/wmi.c     |  10 ++
>  8 files changed, 393 insertions(+), 1 deletion(-)
> 


-- 
Florian


From kuba at kernel.org  Fri Jul 31 16:31:41 2020
From: kuba at kernel.org (Jakub Kicinski)
Date: Fri, 31 Jul 2020 13:31:41 -0700
Subject: [PATCH v2 0/3]
In-Reply-To: <1596220042-2778-1-git-send-email-pillair@codeaurora.org>
References: <1596220042-2778-1-git-send-email-pillair@codeaurora.org>
Message-ID: <20200731133141.68d7ad81@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>

On Fri, 31 Jul 2020 23:57:19 +0530 Rakesh Pillai wrote:
> The history recording will be compiled only if
> ATH10K_DEBUG is enabled, and also enabled via
> the module parameter. Once the history recording
> is enabled via module parameter, it can be enabled
> or disabled runtime via debugfs.

Have you seen the trace_devlink_hwmsg() interface?
Could it be used here?


From briannorris at chromium.org  Fri Jul 31 21:31:27 2020
From: briannorris at chromium.org (Brian Norris)
Date: Fri, 31 Jul 2020 18:31:27 -0700
Subject: [PATCH 1/2] nl80211: vendor-cmd: qca: add dynamic SAR power limits
In-Reply-To: <c3ef60c2263a6840d21f6a797ad3ffb685a728b8.camel@sipsolutions.net>
References: <1576684108-30177-1-git-send-email-kvalo@codeaurora.org>
 <1576684108-30177-2-git-send-email-kvalo@codeaurora.org>
 <1576748692.7758.17.camel@realtek.com>
 <20191219154828.GA12287@w1.fi>
 <CA+ASDXMTYLGbEkBPHSqtyitMEvY5o_MjU0s+NoWdnN_ORy1gDw@mail.gmail.com>
 <20191219185522.GA16010@w1.fi>
 <CA+ASDXNOxkrZTxL0Jo4ONR2YtL83BVc_w-rBXc6ggBLdwUpDZw@mail.gmail.com>
 <871rpqly6a.fsf@kamboji.qca.qualcomm.com>
 <e8908eafd8e6050eef8782c6a7019e318d14f65f.camel@sipsolutions.net>
 <CA+ASDXMf7iXuE9hQ-XitPPfvXP0EK5FchJLCu2+5Ag=ZC=0H0w@mail.gmail.com>
 <87lfjjx0o7.fsf@codeaurora.org>
 <CA+ASDXOAzPuOn_rMsRj4t56kC-TgoG0p5WhSTPJjB8xTTq5kfg@mail.gmail.com>
 <87y2n9clhj.fsf@codeaurora.org>
 <c3ef60c2263a6840d21f6a797ad3ffb685a728b8.camel@sipsolutions.net>
Message-ID: <CA+ASDXOwARX86GzMsSL4N94-jQ-TqAhe07f0AZOQcdKpPyJEgw@mail.gmail.com>

On Thu, Jul 30, 2020 at 6:24 AM Johannes Berg <johannes at sipsolutions.net> wrote:

> > Good, I was just checking that we all are on the same page.
>
> But are we? ;-)

I think you were deferring to, "how would user space use it?" And,
"would a common API really help anyone?" (And then you implied
"anyone" = "Chrome OS.")

I expressed a moderate benefit from a common API, but I'd settle for a
non-common (but upstream) one instead. I also doubt many
non-hardware-customized Linux distributions will make use of this any
time soon.

I don't think that implied you were truly on a different page. But
your response below may say otherwise:

> I don't really see anything in the new proposal [1] that really explains
> why the common API that we've sort of vaguely outlined in this thread
> couldn't work? It just speaks of technical difficulties ("need a
> reporting API too"), but should we let that stop us?
>
> [1] https://patchwork.kernel.org/patch/11686317/

Indeed, I don't see any reason beyond technical difficulties.

I'd love to have a few extra hours in my day to spend on writing such
an API, if that would really unblock months of deadlock.
Unfortunately, those hours tend to get eaten by all sorts of other
things these days, so an honest assessment would probably say I won't
get around to it soon. SAR regulatory concerns aren't really sexy
enough to convince me to spend my weekends on it... (...oh wait, it's
Friday evening already. Hmm.)

Regards,
Brian


