[RFC 0/5] ath6kl: non WMI data service support

[RFC 0/5] ath6kl: non WMI data service support

[Erik Stromdahl]

This patch series is intended to prepare the ath6kl driver
for newer chipsets that doesn't use the current WMI data
endpoints for data traffic.

The chipset I have been working with (and used for testing)
is QCA6584. It is SDIO based (at least the variant I have
been using) with 802.11p WAVE DSRC capabilities.

This chipset is different from the AR600X family in that
it does not use the WMI data services (service id's 0x101
to 0x104 ) for data traffic.
Instead it uses the HTT data service for data and wmi unified
for control messages.
It is also different when it comes to mailbox addresses
and HTC header format as well, but these differences are not
part of this patch series.

Erik Stromdahl (5):
  ath6kl: HTC mbox tx complete cb support
  ath6kl: Updated TARG_VTOP macro with default value
  ath6kl: Added disable credit flow ctrl for mbox
  ath6kl: Updated credit setup
  ath6kl: service connect rewrite

 drivers/net/wireless/ath/ath6kl/core.h     |   3 +
 drivers/net/wireless/ath/ath6kl/htc-ops.h  |   2 +-
 drivers/net/wireless/ath/ath6kl/htc.h      |   4 +-
 drivers/net/wireless/ath/ath6kl/htc_mbox.c |  75 +++++-------
 drivers/net/wireless/ath/ath6kl/htc_pipe.c |  16 +--
 drivers/net/wireless/ath/ath6kl/init.c     | 187 +++++++++++++++++------------
 drivers/net/wireless/ath/ath6kl/target.h   |   4 +-
 7 files changed, 156 insertions(+), 135 deletions(-)

-- 
2.1.4

[RFC 1/5] ath6kl: HTC mbox tx complete cb support

[Erik Stromdahl]

The current implementation always call ath6kl_tx_complete
regardless if a tx_complete callback has been associated with the
endpoint or not.

This patch fixes this by calling the associated callback in case
it is present.

Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
---
 drivers/net/wireless/ath/ath6kl/htc_mbox.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath6kl/htc_mbox.c b/drivers/net/wireless/ath/ath6kl/htc_mbox.c
index 65c31da..6e8c493 100644
--- a/drivers/net/wireless/ath/ath6kl/htc_mbox.c
+++ b/drivers/net/wireless/ath/ath6kl/htc_mbox.c
@@ -445,7 +445,10 @@ static void htc_tx_complete(struct htc_endpoint *endpoint,
 		   "htc tx complete ep %d pkts %d\n",
 		   endpoint->eid, get_queue_depth(txq));
 
-	ath6kl_tx_complete(endpoint->target, txq);
+	if (endpoint->ep_cb.tx_comp_multi)
+		endpoint->ep_cb.tx_comp_multi(endpoint->target, txq);
+	else
+		ath6kl_tx_complete(endpoint->target, txq);
 }
 
 static void htc_tx_comp_handler(struct htc_target *target,
-- 
2.1.4

[RFC 2/5] ath6kl: Updated TARG_VTOP macro with default value

[Erik Stromdahl]

A minor modification of the TARG_VTOP macro.
The AR6004 VTOP macro is used as default (for all
chip's except AR6003)

Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
---
 drivers/net/wireless/ath/ath6kl/target.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath6kl/target.h b/drivers/net/wireless/ath/ath6kl/target.h
index d5eeeae..c6c49b0 100644
--- a/drivers/net/wireless/ath/ath6kl/target.h
+++ b/drivers/net/wireless/ath/ath6kl/target.h
@@ -331,11 +331,11 @@ struct host_interest {
 
 /* Convert a Target virtual address into a Target physical address */
 #define AR6003_VTOP(vaddr) ((vaddr) & 0x001fffff)
-#define AR6004_VTOP(vaddr) (vaddr)
+#define DEFAULT_VTOP(vaddr) (vaddr)
 
 #define TARG_VTOP(target_type, vaddr) \
 	(((target_type) == TARGET_TYPE_AR6003) ? AR6003_VTOP(vaddr) : \
-	(((target_type) == TARGET_TYPE_AR6004) ? AR6004_VTOP(vaddr) : 0))
+	DEFAULT_VTOP(vaddr))
 
 #define ATH6KL_FWLOG_PAYLOAD_SIZE		1500
 
-- 
2.1.4

[RFC 3/5] ath6kl: Added disable credit flow ctrl for mbox

[Erik Stromdahl]

Added support for disabling credit flow control for htc_mbox
in a similar way as htc_pipe.

The tx_credit_flow_enabled member was moved out from the pipe
struct in struct htc_endpoint since it is now used by htc_mbox
as well.

Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
---
 drivers/net/wireless/ath/ath6kl/htc.h      |  2 +-
 drivers/net/wireless/ath/ath6kl/htc_mbox.c | 18 ++++++++++++++++--
 drivers/net/wireless/ath/ath6kl/htc_pipe.c | 14 +++++++-------
 3 files changed, 24 insertions(+), 10 deletions(-)

diff --git a/drivers/net/wireless/ath/ath6kl/htc.h b/drivers/net/wireless/ath/ath6kl/htc.h
index 112d8a9..532b13b 100644
--- a/drivers/net/wireless/ath/ath6kl/htc.h
+++ b/drivers/net/wireless/ath/ath6kl/htc.h
@@ -521,12 +521,12 @@ struct htc_endpoint {
 	u32 conn_flags;
 	struct htc_endpoint_stats ep_st;
 	u16 tx_drop_packet_threshold;
+	bool tx_credit_flow_enabled;
 
 	struct {
 		u8 pipeid_ul;
 		u8 pipeid_dl;
 		struct list_head tx_lookup_queue;
-		bool tx_credit_flow_enabled;
 	} pipe;
 };
 
diff --git a/drivers/net/wireless/ath/ath6kl/htc_mbox.c b/drivers/net/wireless/ath/ath6kl/htc_mbox.c
index 6e8c493..2c4477d 100644
--- a/drivers/net/wireless/ath/ath6kl/htc_mbox.c
+++ b/drivers/net/wireless/ath/ath6kl/htc_mbox.c
@@ -603,7 +603,7 @@ static void ath6kl_htc_tx_pkts_get(struct htc_target *target,
 				   struct htc_endpoint *endpoint,
 				   struct list_head *queue)
 {
-	int req_cred;
+	int req_cred = 0;
 	u8 flags;
 	struct htc_packet *packet;
 	unsigned int len;
@@ -623,7 +623,8 @@ static void ath6kl_htc_tx_pkts_get(struct htc_target *target,
 		len = CALC_TXRX_PADDED_LEN(target,
 					   packet->act_len + HTC_HDR_LENGTH);
 
-		if (htc_check_credits(target, endpoint, &flags,
+		if (endpoint->tx_credit_flow_enabled &&
+		    htc_check_credits(target, endpoint, &flags,
 				      packet->endpoint, len, &req_cred))
 			break;
 
@@ -2434,6 +2435,7 @@ static int ath6kl_htc_mbox_conn_service(struct htc_target *target,
 	struct htc_conn_service_msg *conn_msg;
 	struct htc_endpoint *endpoint;
 	enum htc_endpoint_id assigned_ep = ENDPOINT_MAX;
+	bool disable_credit_flowctrl = false;
 	unsigned int max_msg_sz = 0;
 	int status = 0;
 	u16 msg_id;
@@ -2459,6 +2461,10 @@ static int ath6kl_htc_mbox_conn_service(struct htc_target *target,
 		conn_msg->svc_id = cpu_to_le16(conn_req->svc_id);
 		conn_msg->conn_flags = cpu_to_le16(conn_req->conn_flags);
 
+		if (conn_req->conn_flags &
+		    HTC_CONN_FLGS_DISABLE_CRED_FLOW_CTRL)
+			disable_credit_flowctrl = true;
+
 		set_htc_pkt_info(tx_pkt, NULL, (u8 *) conn_msg,
 				 sizeof(*conn_msg) + conn_msg->svc_meta_len,
 				 ENDPOINT_0, HTC_SERVICE_TX_PACKET_TAG);
@@ -2562,6 +2568,13 @@ static int ath6kl_htc_mbox_conn_service(struct htc_target *target,
 	/* save local connection flags */
 	endpoint->conn_flags = conn_req->flags;
 
+	if (disable_credit_flowctrl && endpoint->tx_credit_flow_enabled) {
+		endpoint->tx_credit_flow_enabled = false;
+		ath6kl_dbg(ATH6KL_DBG_HTC,
+			   "SVC: 0x%4.4X ep:%d TX flow control off\n",
+			   endpoint->svc_id, assigned_ep);
+	}
+
 fail_tx:
 	if (tx_pkt)
 		htc_reclaim_txctrl_buf(target, tx_pkt);
@@ -2590,6 +2603,7 @@ static void reset_ep_state(struct htc_target *target)
 		INIT_LIST_HEAD(&endpoint->rx_bufq);
 		INIT_LIST_HEAD(&endpoint->txq);
 		endpoint->target = target;
+		endpoint->tx_credit_flow_enabled = true;
 	}
 
 	/* reset distribution list */
diff --git a/drivers/net/wireless/ath/ath6kl/htc_pipe.c b/drivers/net/wireless/ath/ath6kl/htc_pipe.c
index ca1a18c..93aac63 100644
--- a/drivers/net/wireless/ath/ath6kl/htc_pipe.c
+++ b/drivers/net/wireless/ath/ath6kl/htc_pipe.c
@@ -408,7 +408,7 @@ static enum htc_send_queue_result htc_try_send(struct htc_target *target,
 		}
 	}
 
-	if (!ep->pipe.tx_credit_flow_enabled) {
+	if (!ep->tx_credit_flow_enabled) {
 		tx_resources =
 		    ath6kl_hif_pipe_get_free_queue_number(ar,
 							  ep->pipe.pipeid_ul);
@@ -452,7 +452,7 @@ static enum htc_send_queue_result htc_try_send(struct htc_target *target,
 		if (get_queue_depth(&ep->txq) == 0)
 			break;
 
-		if (ep->pipe.tx_credit_flow_enabled) {
+		if (ep->tx_credit_flow_enabled) {
 			/*
 			 * Credit based mechanism provides flow control
 			 * based on target transmit resource availability,
@@ -482,7 +482,7 @@ static enum htc_send_queue_result htc_try_send(struct htc_target *target,
 		/* send what we can */
 		htc_issue_packets(target, ep, &send_queue);
 
-		if (!ep->pipe.tx_credit_flow_enabled) {
+		if (!ep->tx_credit_flow_enabled) {
 			pipeid = ep->pipe.pipeid_ul;
 			tx_resources =
 			    ath6kl_hif_pipe_get_free_queue_number(ar, pipeid);
@@ -768,7 +768,7 @@ static int ath6kl_htc_pipe_tx_complete(struct ath6kl *ar, struct sk_buff *skb)
 	}
 	skb = NULL;
 
-	if (!ep->pipe.tx_credit_flow_enabled) {
+	if (!ep->tx_credit_flow_enabled) {
 		/*
 		 * note: when using TX credit flow, the re-checking of queues
 		 * happens when credits flow back from the target. in the
@@ -1194,7 +1194,7 @@ static void reset_endpoint_states(struct htc_target *target)
 		INIT_LIST_HEAD(&ep->pipe.tx_lookup_queue);
 		INIT_LIST_HEAD(&ep->rx_bufq);
 		ep->target = target;
-		ep->pipe.tx_credit_flow_enabled = true;
+		ep->tx_credit_flow_enabled = true;
 	}
 }
 
@@ -1399,8 +1399,8 @@ static int ath6kl_htc_pipe_conn_service(struct htc_target *target,
 		   ep->svc_id, ep->pipe.pipeid_ul,
 		   ep->pipe.pipeid_dl, ep->eid);
 
-	if (disable_credit_flowctrl && ep->pipe.tx_credit_flow_enabled) {
-		ep->pipe.tx_credit_flow_enabled = false;
+	if (disable_credit_flowctrl && ep->tx_credit_flow_enabled) {
+		ep->tx_credit_flow_enabled = false;
 		ath6kl_dbg(ATH6KL_DBG_HTC,
 			   "SVC: 0x%4.4X ep:%d TX flow control off\n",
 			   ep->svc_id, assigned_epid);
-- 
2.1.4

[RFC 4/5] ath6kl: Updated credit setup

[Erik Stromdahl]

This patch simplifies the credit setup and removes a dependency
from htc_mbox.c.

The service priority (the order in which the endpoint credits are
added in target->cred_dist_list) is now determined by the sequence
in which the host connects to services.

The HTC control endpoint will have highest prio (just as before) since
it is the first endpoint that is connected (done in htc_wait_target).
The remaining service prio's will be prioritized in the order in
which they are connected.

The rationale behind this patch is to remove the service
dependecies (the prio list in ath6kl_htc_mbox_credit_setup) from
htc_mbox.c.

Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
---
 drivers/net/wireless/ath/ath6kl/htc_mbox.c | 50 ++++++------------------------
 1 file changed, 9 insertions(+), 41 deletions(-)

diff --git a/drivers/net/wireless/ath/ath6kl/htc_mbox.c b/drivers/net/wireless/ath/ath6kl/htc_mbox.c
index 2c4477d..eed3939 100644
--- a/drivers/net/wireless/ath/ath6kl/htc_mbox.c
+++ b/drivers/net/wireless/ath/ath6kl/htc_mbox.c
@@ -29,9 +29,6 @@ static void ath6kl_htc_mbox_cleanup(struct htc_target *target);
 static void ath6kl_htc_mbox_stop(struct htc_target *target);
 static int ath6kl_htc_mbox_add_rxbuf_multiple(struct htc_target *target,
 					      struct list_head *pkt_queue);
-static void ath6kl_htc_set_credit_dist(struct htc_target *target,
-				       struct ath6kl_htc_credit_info *cred_info,
-				       u16 svc_pri_order[], int len);
 
 /* threshold to re-enable Tx bundling for an AC*/
 #define TX_RESUME_BUNDLE_THRESHOLD	1500
@@ -146,18 +143,9 @@ static void ath6kl_credit_init(struct ath6kl_htc_credit_info *cred_info,
 static int ath6kl_htc_mbox_credit_setup(struct htc_target *htc_target,
 			       struct ath6kl_htc_credit_info *cred_info)
 {
-	u16 servicepriority[5];
-
 	memset(cred_info, 0, sizeof(struct ath6kl_htc_credit_info));
 
-	servicepriority[0] = WMI_CONTROL_SVC;  /* highest */
-	servicepriority[1] = WMI_DATA_VO_SVC;
-	servicepriority[2] = WMI_DATA_VI_SVC;
-	servicepriority[3] = WMI_DATA_BE_SVC;
-	servicepriority[4] = WMI_DATA_BK_SVC; /* lowest */
-
-	/* set priority list */
-	ath6kl_htc_set_credit_dist(htc_target, cred_info, servicepriority, 5);
+	htc_target->credit_info = cred_info;
 
 	return 0;
 }
@@ -1094,34 +1082,6 @@ static int htc_setup_tx_complete(struct htc_target *target)
 	return status;
 }
 
-static void ath6kl_htc_set_credit_dist(struct htc_target *target,
-				struct ath6kl_htc_credit_info *credit_info,
-				u16 srvc_pri_order[], int list_len)
-{
-	struct htc_endpoint *endpoint;
-	int i, ep;
-
-	target->credit_info = credit_info;
-
-	list_add_tail(&target->endpoint[ENDPOINT_0].cred_dist.list,
-		      &target->cred_dist_list);
-
-	for (i = 0; i < list_len; i++) {
-		for (ep = ENDPOINT_1; ep < ENDPOINT_MAX; ep++) {
-			endpoint = &target->endpoint[ep];
-			if (endpoint->svc_id == srvc_pri_order[i]) {
-				list_add_tail(&endpoint->cred_dist.list,
-					      &target->cred_dist_list);
-				break;
-			}
-		}
-		if (ep >= ENDPOINT_MAX) {
-			WARN_ON(1);
-			return;
-		}
-	}
-}
-
 static int ath6kl_htc_mbox_tx(struct htc_target *target,
 			      struct htc_packet *packet)
 {
@@ -2575,6 +2535,14 @@ static int ath6kl_htc_mbox_conn_service(struct htc_target *target,
 			   endpoint->svc_id, assigned_ep);
 	}
 
+	/* Add the credit distribution list of the current endpoint
+	 * to target->cred_dist_list.
+	 * The order in which this function is called will determine
+	 * the priority of the services.
+	 */
+	list_add_tail(&endpoint->cred_dist.list,
+		      &target->cred_dist_list);
+
 fail_tx:
 	if (tx_pkt)
 		htc_reclaim_txctrl_buf(target, tx_pkt);
-- 
2.1.4

[RFC 5/5] ath6kl: service connect rewrite

[Erik Stromdahl]

This patch removes the hardcoded struct
htc_service_connect_req from ath6kl_init_service_ep and adds
an array of struct htc_service_connect_req's to each element
in hw_list.

The rationale behind this patch is to make it possible to select
which services to connect to depending on chipset.

Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
---
 drivers/net/wireless/ath/ath6kl/core.h     |   3 +
 drivers/net/wireless/ath/ath6kl/htc-ops.h  |   2 +-
 drivers/net/wireless/ath/ath6kl/htc.h      |   2 +-
 drivers/net/wireless/ath/ath6kl/htc_mbox.c |   2 +-
 drivers/net/wireless/ath/ath6kl/htc_pipe.c |   2 +-
 drivers/net/wireless/ath/ath6kl/init.c     | 187 +++++++++++++++++------------
 6 files changed, 117 insertions(+), 81 deletions(-)

diff --git a/drivers/net/wireless/ath/ath6kl/core.h b/drivers/net/wireless/ath/ath6kl/core.h
index ac25f17..f907ef4 100644
--- a/drivers/net/wireless/ath/ath6kl/core.h
+++ b/drivers/net/wireless/ath/ath6kl/core.h
@@ -799,6 +799,9 @@ struct ath6kl {
 			const char *testscript;
 		} fw;
 
+		const struct htc_service_connect_req *services;
+		u32 service_count;
+
 		const char *fw_board;
 		const char *fw_default_board;
 	} hw;
diff --git a/drivers/net/wireless/ath/ath6kl/htc-ops.h b/drivers/net/wireless/ath/ath6kl/htc-ops.h
index 2d4eed5..80700a4 100644
--- a/drivers/net/wireless/ath/ath6kl/htc-ops.h
+++ b/drivers/net/wireless/ath/ath6kl/htc-ops.h
@@ -36,7 +36,7 @@ static inline int ath6kl_htc_start(struct htc_target *target)
 }
 
 static inline int ath6kl_htc_conn_service(struct htc_target *target,
-					  struct htc_service_connect_req *req,
+					  const struct htc_service_connect_req *req,
 					  struct htc_service_connect_resp *resp)
 {
 	return target->dev->ar->htc_ops->conn_service(target, req, resp);
diff --git a/drivers/net/wireless/ath/ath6kl/htc.h b/drivers/net/wireless/ath/ath6kl/htc.h
index 532b13b..bfff466 100644
--- a/drivers/net/wireless/ath/ath6kl/htc.h
+++ b/drivers/net/wireless/ath/ath6kl/htc.h
@@ -550,7 +550,7 @@ struct ath6kl_htc_ops {
 	int (*wait_target)(struct htc_target *target);
 	int (*start)(struct htc_target *target);
 	int (*conn_service)(struct htc_target *target,
-			    struct htc_service_connect_req *req,
+			    const struct htc_service_connect_req *req,
 			    struct htc_service_connect_resp *resp);
 	int  (*tx)(struct htc_target *target, struct htc_packet *packet);
 	void (*stop)(struct htc_target *target);
diff --git a/drivers/net/wireless/ath/ath6kl/htc_mbox.c b/drivers/net/wireless/ath/ath6kl/htc_mbox.c
index eed3939..24fb9a7 100644
--- a/drivers/net/wireless/ath/ath6kl/htc_mbox.c
+++ b/drivers/net/wireless/ath/ath6kl/htc_mbox.c
@@ -2386,7 +2386,7 @@ static void ath6kl_htc_mbox_flush_rx_buf(struct htc_target *target)
 }
 
 static int ath6kl_htc_mbox_conn_service(struct htc_target *target,
-			    struct htc_service_connect_req *conn_req,
+			    const struct htc_service_connect_req *conn_req,
 			    struct htc_service_connect_resp *conn_resp)
 {
 	struct htc_packet *rx_pkt = NULL;
diff --git a/drivers/net/wireless/ath/ath6kl/htc_pipe.c b/drivers/net/wireless/ath/ath6kl/htc_pipe.c
index 93aac63..9a39f3d 100644
--- a/drivers/net/wireless/ath/ath6kl/htc_pipe.c
+++ b/drivers/net/wireless/ath/ath6kl/htc_pipe.c
@@ -1226,7 +1226,7 @@ static u8 htc_get_credit_alloc(struct htc_target *target, u16 service_id)
 }
 
 static int ath6kl_htc_pipe_conn_service(struct htc_target *target,
-		     struct htc_service_connect_req *conn_req,
+		     const struct htc_service_connect_req *conn_req,
 		     struct htc_service_connect_resp *conn_resp)
 {
 	struct ath6kl *ar = target->dev->ar;
diff --git a/drivers/net/wireless/ath/ath6kl/init.c b/drivers/net/wireless/ath/ath6kl/init.c
index 58fb227..a4c7abe 100644
--- a/drivers/net/wireless/ath/ath6kl/init.c
+++ b/drivers/net/wireless/ath/ath6kl/init.c
@@ -32,6 +32,94 @@
 #include "hif-ops.h"
 #include "htc-ops.h"
 
+const struct htc_service_connect_req ar600x_services[] = {
+	{
+		.svc_id = WMI_CONTROL_SVC,
+		.ep_cb = {
+			.tx_comp_multi = ath6kl_tx_complete,
+			.rx = ath6kl_rx,
+			.rx_refill = ath6kl_rx_refill,
+			.tx_full = ath6kl_tx_queue_full,
+			.rx_refill_thresh = ATH6KL_MAX_RX_BUFFERS / 4,
+		},
+		.max_txq_depth = MAX_DEFAULT_SEND_QUEUE_DEPTH,
+	},
+	{
+		.svc_id = WMI_DATA_BE_SVC,
+		.conn_flags = HTC_CONN_FLGS_REDUCE_CRED_DRIB |
+			      HTC_CONN_FLGS_THRESH_LVL_HALF,
+		.ep_cb = {
+			.tx_comp_multi = ath6kl_tx_complete,
+			.rx = ath6kl_rx,
+			.rx_refill = ath6kl_rx_refill,
+			.tx_full = ath6kl_tx_queue_full,
+			.rx_refill_thresh = ATH6KL_MAX_RX_BUFFERS / 4,
+			.rx_alloc_thresh = ATH6KL_BUFFER_SIZE,
+			.rx_allocthresh = ath6kl_alloc_amsdu_rxbuf,
+		},
+		.max_txq_depth = MAX_DEFAULT_SEND_QUEUE_DEPTH,
+		.flags = HTC_FLGS_TX_BNDL_PAD_EN,
+		.max_rxmsg_sz = WMI_MAX_TX_DATA_FRAME_LENGTH,
+	},
+	{
+		.svc_id = WMI_DATA_BK_SVC,
+		.conn_flags = HTC_CONN_FLGS_REDUCE_CRED_DRIB |
+			      HTC_CONN_FLGS_THRESH_LVL_HALF,
+		.ep_cb = {
+			.tx_comp_multi = ath6kl_tx_complete,
+			.rx = ath6kl_rx,
+			.rx_refill = ath6kl_rx_refill,
+			.tx_full = ath6kl_tx_queue_full,
+			.rx_refill_thresh = ATH6KL_MAX_RX_BUFFERS / 4,
+			.rx_alloc_thresh = ATH6KL_BUFFER_SIZE,
+			.rx_allocthresh = ath6kl_alloc_amsdu_rxbuf,
+		},
+		.max_txq_depth = MAX_DEFAULT_SEND_QUEUE_DEPTH,
+		.flags = HTC_FLGS_TX_BNDL_PAD_EN,
+		.max_rxmsg_sz = WMI_MAX_TX_DATA_FRAME_LENGTH,
+	},
+	{
+		.svc_id = WMI_DATA_VI_SVC,
+		.conn_flags = HTC_CONN_FLGS_REDUCE_CRED_DRIB |
+			      HTC_CONN_FLGS_THRESH_LVL_HALF,
+		.ep_cb = {
+			.tx_comp_multi = ath6kl_tx_complete,
+			.rx = ath6kl_rx,
+			.rx_refill = ath6kl_rx_refill,
+			.tx_full = ath6kl_tx_queue_full,
+			.rx_refill_thresh = ATH6KL_MAX_RX_BUFFERS / 4,
+			.rx_alloc_thresh = ATH6KL_BUFFER_SIZE,
+			.rx_allocthresh = ath6kl_alloc_amsdu_rxbuf,
+		},
+		.max_txq_depth = MAX_DEFAULT_SEND_QUEUE_DEPTH,
+		.flags = HTC_FLGS_TX_BNDL_PAD_EN,
+		.max_rxmsg_sz = WMI_MAX_TX_DATA_FRAME_LENGTH,
+	},
+	/* VO service, this is currently not mapped to a WMI
+	 * priority stream due to historical reasons. WMI originally
+	 * defined 3 priorities over 3 mailboxes We can change this when
+	 * WMI is reworked so that priorities are not dependent on
+	 * mailboxes.
+	 */
+	{
+		.svc_id = WMI_DATA_VO_SVC,
+		.conn_flags = HTC_CONN_FLGS_REDUCE_CRED_DRIB |
+			      HTC_CONN_FLGS_THRESH_LVL_HALF,
+		.ep_cb = {
+			.tx_comp_multi = ath6kl_tx_complete,
+			.rx = ath6kl_rx,
+			.rx_refill = ath6kl_rx_refill,
+			.tx_full = ath6kl_tx_queue_full,
+			.rx_refill_thresh = ATH6KL_MAX_RX_BUFFERS / 4,
+			.rx_alloc_thresh = ATH6KL_BUFFER_SIZE,
+			.rx_allocthresh = ath6kl_alloc_amsdu_rxbuf,
+		},
+		.max_txq_depth = MAX_DEFAULT_SEND_QUEUE_DEPTH,
+		.flags = HTC_FLGS_TX_BNDL_PAD_EN,
+		.max_rxmsg_sz = WMI_MAX_TX_DATA_FRAME_LENGTH,
+	},
+};
+
 static const struct ath6kl_hw hw_list[] = {
 	{
 		.id				= AR6003_HW_2_0_VERSION,
@@ -57,6 +145,8 @@ static const struct ath6kl_hw hw_list[] = {
 
 		.fw_board		= AR6003_HW_2_0_BOARD_DATA_FILE,
 		.fw_default_board	= AR6003_HW_2_0_DEFAULT_BOARD_DATA_FILE,
+		.services		= ar600x_services,
+		.service_count		= ARRAY_SIZE(ar600x_services),
 	},
 	{
 		.id				= AR6003_HW_2_1_1_VERSION,
@@ -82,6 +172,8 @@ static const struct ath6kl_hw hw_list[] = {
 
 		.fw_board		= AR6003_HW_2_1_1_BOARD_DATA_FILE,
 		.fw_default_board = AR6003_HW_2_1_1_DEFAULT_BOARD_DATA_FILE,
+		.services		= ar600x_services,
+		.service_count		= ARRAY_SIZE(ar600x_services),
 	},
 	{
 		.id				= AR6004_HW_1_0_VERSION,
@@ -102,6 +194,8 @@ static const struct ath6kl_hw hw_list[] = {
 
 		.fw_board		= AR6004_HW_1_0_BOARD_DATA_FILE,
 		.fw_default_board	= AR6004_HW_1_0_DEFAULT_BOARD_DATA_FILE,
+		.services		= ar600x_services,
+		.service_count		= ARRAY_SIZE(ar600x_services),
 	},
 	{
 		.id				= AR6004_HW_1_1_VERSION,
@@ -121,6 +215,8 @@ static const struct ath6kl_hw hw_list[] = {
 
 		.fw_board		= AR6004_HW_1_1_BOARD_DATA_FILE,
 		.fw_default_board	= AR6004_HW_1_1_DEFAULT_BOARD_DATA_FILE,
+		.services		= ar600x_services,
+		.service_count		= ARRAY_SIZE(ar600x_services),
 	},
 	{
 		.id				= AR6004_HW_1_2_VERSION,
@@ -140,6 +236,8 @@ static const struct ath6kl_hw hw_list[] = {
 		},
 		.fw_board		= AR6004_HW_1_2_BOARD_DATA_FILE,
 		.fw_default_board	= AR6004_HW_1_2_DEFAULT_BOARD_DATA_FILE,
+		.services		= ar600x_services,
+		.service_count		= ARRAY_SIZE(ar600x_services),
 	},
 	{
 		.id				= AR6004_HW_1_3_VERSION,
@@ -163,6 +261,8 @@ static const struct ath6kl_hw hw_list[] = {
 
 		.fw_board               = AR6004_HW_1_3_BOARD_DATA_FILE,
 		.fw_default_board       = AR6004_HW_1_3_DEFAULT_BOARD_DATA_FILE,
+		.services		= ar600x_services,
+		.service_count		= ARRAY_SIZE(ar600x_services),
 	},
 	{
 		.id				= AR6004_HW_3_0_VERSION,
@@ -186,6 +286,8 @@ static const struct ath6kl_hw hw_list[] = {
 
 		.fw_board		= AR6004_HW_3_0_BOARD_DATA_FILE,
 		.fw_default_board	= AR6004_HW_3_0_DEFAULT_BOARD_DATA_FILE,
+		.services		= ar600x_services,
+		.service_count		= ARRAY_SIZE(ar600x_services),
 	},
 };
 
@@ -280,8 +382,7 @@ static inline void set_ac2_ep_map(struct ath6kl *ar,
 
 /* connect to a service */
 static int ath6kl_connectservice(struct ath6kl *ar,
-				 struct htc_service_connect_req  *con_req,
-				 char *desc)
+				 const struct htc_service_connect_req  *con_req)
 {
 	int status;
 	struct htc_service_connect_resp response;
@@ -290,8 +391,8 @@ static int ath6kl_connectservice(struct ath6kl *ar,
 
 	status = ath6kl_htc_conn_service(ar->htc_target, con_req, &response);
 	if (status) {
-		ath6kl_err("failed to connect to %s service status:%d\n",
-			   desc, status);
+		ath6kl_err("failed to connect to %x service status: %d\n",
+			   con_req->svc_id, status);
 		return status;
 	}
 
@@ -323,80 +424,12 @@ static int ath6kl_connectservice(struct ath6kl *ar,
 
 static int ath6kl_init_service_ep(struct ath6kl *ar)
 {
-	struct htc_service_connect_req connect;
-
-	memset(&connect, 0, sizeof(connect));
-
-	/* these fields are the same for all service endpoints */
-	connect.ep_cb.tx_comp_multi = ath6kl_tx_complete;
-	connect.ep_cb.rx = ath6kl_rx;
-	connect.ep_cb.rx_refill = ath6kl_rx_refill;
-	connect.ep_cb.tx_full = ath6kl_tx_queue_full;
-
-	/*
-	 * Set the max queue depth so that our ath6kl_tx_queue_full handler
-	 * gets called.
-	*/
-	connect.max_txq_depth = MAX_DEFAULT_SEND_QUEUE_DEPTH;
-	connect.ep_cb.rx_refill_thresh = ATH6KL_MAX_RX_BUFFERS / 4;
-	if (!connect.ep_cb.rx_refill_thresh)
-		connect.ep_cb.rx_refill_thresh++;
-
-	/* connect to control service */
-	connect.svc_id = WMI_CONTROL_SVC;
-	if (ath6kl_connectservice(ar, &connect, "WMI CONTROL"))
-		return -EIO;
-
-	connect.flags |= HTC_FLGS_TX_BNDL_PAD_EN;
-
-	/*
-	 * Limit the HTC message size on the send path, although e can
-	 * receive A-MSDU frames of 4K, we will only send ethernet-sized
-	 * (802.3) frames on the send path.
-	 */
-	connect.max_rxmsg_sz = WMI_MAX_TX_DATA_FRAME_LENGTH;
-
-	/*
-	 * To reduce the amount of committed memory for larger A_MSDU
-	 * frames, use the recv-alloc threshold mechanism for larger
-	 * packets.
-	 */
-	connect.ep_cb.rx_alloc_thresh = ATH6KL_BUFFER_SIZE;
-	connect.ep_cb.rx_allocthresh = ath6kl_alloc_amsdu_rxbuf;
-
-	/*
-	 * For the remaining data services set the connection flag to
-	 * reduce dribbling, if configured to do so.
-	 */
-	connect.conn_flags |= HTC_CONN_FLGS_REDUCE_CRED_DRIB;
-	connect.conn_flags &= ~HTC_CONN_FLGS_THRESH_MASK;
-	connect.conn_flags |= HTC_CONN_FLGS_THRESH_LVL_HALF;
-
-	connect.svc_id = WMI_DATA_BE_SVC;
-
-	if (ath6kl_connectservice(ar, &connect, "WMI DATA BE"))
-		return -EIO;
-
-	/* connect to back-ground map this to WMI LOW_PRI */
-	connect.svc_id = WMI_DATA_BK_SVC;
-	if (ath6kl_connectservice(ar, &connect, "WMI DATA BK"))
-		return -EIO;
-
-	/* connect to Video service, map this to HI PRI */
-	connect.svc_id = WMI_DATA_VI_SVC;
-	if (ath6kl_connectservice(ar, &connect, "WMI DATA VI"))
-		return -EIO;
+	int i;
 
-	/*
-	 * Connect to VO service, this is currently not mapped to a WMI
-	 * priority stream due to historical reasons. WMI originally
-	 * defined 3 priorities over 3 mailboxes We can change this when
-	 * WMI is reworked so that priorities are not dependent on
-	 * mailboxes.
-	 */
-	connect.svc_id = WMI_DATA_VO_SVC;
-	if (ath6kl_connectservice(ar, &connect, "WMI DATA VO"))
-		return -EIO;
+	for (i = 0; i < ar->hw.service_count; i++) {
+		if (ath6kl_connectservice(ar, &ar->hw.services[i]))
+			return -EIO;
+	}
 
 	return 0;
 }
-- 
2.1.4

Re: [RFC 0/5] ath6kl: non WMI data service support

[Steve deRosier]

Hi Eric,

On Thu, Oct 13, 2016 at 9:39 AM, Erik Stromdahl
<erik.stromdahl@gmail.com> wrote:
> This patch series is intended to prepare the ath6kl driver
> for newer chipsets that doesn't use the current WMI data
> endpoints for data traffic.
>
> The chipset I have been working with (and used for testing)
> is QCA6584. It is SDIO based (at least the variant I have
> been using) with 802.11p WAVE DSRC capabilities.
>
> This chipset is different from the AR600X family in that
> it does not use the WMI data services (service id's 0x101
> to 0x104 ) for data traffic.
> Instead it uses the HTT data service for data and wmi unified
> for control messages.
> It is also different when it comes to mailbox addresses
> and HTC header format as well, but these differences are not
> part of this patch series.
>

I've only taken a quick look and I'll make specific comments to
specific patches later, but I've got to ask the question, should these
changes go into ath6kl or be a new driver?

Just because the number starts with 6000 doesn't mean it's a ath6kl
chip. The 10k series chips all start with 9000 for example, but they
rate their own driver.

You state that all of the underpinnings of the communication with the
chip are totally different:
* Doesn't use WMI
* Different mailboxing
* Different HTC layer

If all of the commands and all of the communication layers to the chip
are totally different, then perhaps it isn't an ath6kl chip. So if
it's largely similar, then OK, but seems to me with the changes you're
saying above, it's mostly different.

I'm saying all that without any knowledge of this chip. My experience
is limited to various versions of the 6003 and 6004 chips.

Just trying to stimulate discussion here.

Thanks,
- Steve

Re: [RFC 0/5] ath6kl: non WMI data service support

[Valo, Kalle]

Steve deRosier <derosier@gmail.com> writes:

> Hi Eric,
>
> On Thu, Oct 13, 2016 at 9:39 AM, Erik Stromdahl
> <erik.stromdahl@gmail.com> wrote:
>> This patch series is intended to prepare the ath6kl driver
>> for newer chipsets that doesn't use the current WMI data
>> endpoints for data traffic.
>>
>> The chipset I have been working with (and used for testing)
>> is QCA6584. It is SDIO based (at least the variant I have
>> been using) with 802.11p WAVE DSRC capabilities.
>>
>> This chipset is different from the AR600X family in that
>> it does not use the WMI data services (service id's 0x101
>> to 0x104 ) for data traffic.
>> Instead it uses the HTT data service for data and wmi unified
>> for control messages.
>> It is also different when it comes to mailbox addresses
>> and HTC header format as well, but these differences are not
>> part of this patch series.
>>
>
> I've only taken a quick look and I'll make specific comments to
> specific patches later, but I've got to ask the question, should these
> changes go into ath6kl or be a new driver?
>
> Just because the number starts with 6000 doesn't mean it's a ath6kl
> chip. The 10k series chips all start with 9000 for example, but they
> rate their own driver.
>
> You state that all of the underpinnings of the communication with the
> chip are totally different:
> * Doesn't use WMI
> * Different mailboxing
> * Different HTC layer
>
> If all of the commands and all of the communication layers to the chip
> are totally different, then perhaps it isn't an ath6kl chip. So if
> it's largely similar, then OK, but seems to me with the changes you're
> saying above, it's mostly different.
>
> I'm saying all that without any knowledge of this chip. My experience
> is limited to various versions of the 6003 and 6004 chips.

Exactly what I was thinking. When I saw terms like "HTT" and "unified
WMI" my first thought was that is this actually an ath10k based design?
The product numbers really don't give any indication what driver
supports, the division goes something like this:

* ath9k: "non-mobile" 11n chips
* ath6k: mobile 11n chips
* ath10k: mobile and "non-mobile" 11ac chips

For example QCA6174 is an 11ac mobile chip supported by ath10k. ath10k
only supports PCI bus at the moment, but I'm hoping someone would add
USB and SDIO support. Patches are very welcome.

I'm starting to suspect that QCA6584 is actually based on the same
design as QCA6174. If that's the case when we should also think if
instead we should add SDIO support to ath10k, maybe by taking relevant
parts from ath6kl?

I'll investigate more what this QCA6584 is, I haven't heard about it
before.

--=20
Kalle Valo=

Re: [RFC 0/5] ath6kl: non WMI data service support

[Valo, Kalle]

Erik Stromdahl <erik.stromdahl@gmail.com> writes:

> This patch series is intended to prepare the ath6kl driver
> for newer chipsets that doesn't use the current WMI data
> endpoints for data traffic.
>
> The chipset I have been working with (and used for testing)
> is QCA6584. It is SDIO based (at least the variant I have
> been using) with 802.11p WAVE DSRC capabilities.
>
> This chipset is different from the AR600X family in that
> it does not use the WMI data services (service id's 0x101
> to 0x104 ) for data traffic.
> Instead it uses the HTT data service for data and wmi unified
> for control messages.
> It is also different when it comes to mailbox addresses
> and HTC header format as well, but these differences are not
> part of this patch series.

Do you have more patches implemented, like something already working or
have just started?

--=20
Kalle Valo=

Re: [RFC 0/5] ath6kl: non WMI data service support

[Erik Stromdahl]

On 10/14/2016 06:32 AM, Valo, Kalle wrote:
> Steve deRosier <derosier@gmail.com> writes:
> 
>> Hi Eric,
>>
>> On Thu, Oct 13, 2016 at 9:39 AM, Erik Stromdahl
>> <erik.stromdahl@gmail.com> wrote:
>>> This patch series is intended to prepare the ath6kl driver
>>> for newer chipsets that doesn't use the current WMI data
>>> endpoints for data traffic.
>>>
>>> The chipset I have been working with (and used for testing)
>>> is QCA6584. It is SDIO based (at least the variant I have
>>> been using) with 802.11p WAVE DSRC capabilities.
>>>
>>> This chipset is different from the AR600X family in that
>>> it does not use the WMI data services (service id's 0x101
>>> to 0x104 ) for data traffic.
>>> Instead it uses the HTT data service for data and wmi unified
>>> for control messages.
>>> It is also different when it comes to mailbox addresses
>>> and HTC header format as well, but these differences are not
>>> part of this patch series.
>>>
>>
>> I've only taken a quick look and I'll make specific comments to
>> specific patches later, but I've got to ask the question, should these
>> changes go into ath6kl or be a new driver?
>>
>> Just because the number starts with 6000 doesn't mean it's a ath6kl
>> chip. The 10k series chips all start with 9000 for example, but they
>> rate their own driver.
>>
>> You state that all of the underpinnings of the communication with the
>> chip are totally different:
>> * Doesn't use WMI
>> * Different mailboxing
>> * Different HTC layer
>>
>> If all of the commands and all of the communication layers to the chip
>> are totally different, then perhaps it isn't an ath6kl chip. So if
>> it's largely similar, then OK, but seems to me with the changes you're
>> saying above, it's mostly different.
>>
>> I'm saying all that without any knowledge of this chip. My experience
>> is limited to various versions of the 6003 and 6004 chips.
> 
> Exactly what I was thinking. When I saw terms like "HTT" and "unified
> WMI" my first thought was that is this actually an ath10k based design?
> The product numbers really don't give any indication what driver
> supports, the division goes something like this:
> 
> * ath9k: "non-mobile" 11n chips
> * ath6k: mobile 11n chips
> * ath10k: mobile and "non-mobile" 11ac chips
> 
> For example QCA6174 is an 11ac mobile chip supported by ath10k. ath10k
> only supports PCI bus at the moment, but I'm hoping someone would add
> USB and SDIO support. Patches are very welcome.
> 
> I'm starting to suspect that QCA6584 is actually based on the same
> design as QCA6174. If that's the case when we should also think if
> instead we should add SDIO support to ath10k, maybe by taking relevant
> parts from ath6kl?
> 
> I'll investigate more what this QCA6584 is, I haven't heard about it
> before.
> 

The reason I have patched to ath6kl driver was that it is the
only driver with sdio/mbox support.

I was actually thinking of writing a new driver from scratch, but I
thought that it was less work to modify the existing ath6kl driver.

I just haven't considered the option to add sdio/mbox support to ath10k.
This is definitely something I will have a look at.

I should mention that I have been using the qcacld2.0 driver as
"documentation" of the chipset.

The qcacld driver identifies the chipset as AR6320

>From the qcacld2.0 driver bmi_msg.h:

#define TARGET_TYPE_AR6320    8

Perhaps this can shed some light on what kind of chip this is?

Re: [RFC 0/5] ath6kl: non WMI data service support

[Erik Stromdahl]

On 10/14/2016 09:34 AM, Valo, Kalle wrote:
> Erik Stromdahl <erik.stromdahl@gmail.com> writes:
> 
>> This patch series is intended to prepare the ath6kl driver
>> for newer chipsets that doesn't use the current WMI data
>> endpoints for data traffic.
>>
>> The chipset I have been working with (and used for testing)
>> is QCA6584. It is SDIO based (at least the variant I have
>> been using) with 802.11p WAVE DSRC capabilities.
>>
>> This chipset is different from the AR600X family in that
>> it does not use the WMI data services (service id's 0x101
>> to 0x104 ) for data traffic.
>> Instead it uses the HTT data service for data and wmi unified
>> for control messages.
>> It is also different when it comes to mailbox addresses
>> and HTC header format as well, but these differences are not
>> part of this patch series.
> 
> Do you have more patches implemented, like something already working or
> have just started?
> 

I have an implementation with all features I need so far, but the other
patches will require cleanup before I can submit anything.

I have been using the qcacld driver as a basis for the work and some of
the stuff in that driver is not really compliant with the kernel coding
style (to say the least).

I have so far mainly been focused on getting all features up and running
and that has (unfortunately) resulted in some copy-pasting from qcacld.

I will start having a look at ath10k and see how much work it would be
to add sdio support to it...

Re: [RFC 0/5] ath6kl: non WMI data service support

[Valo, Kalle]

(Adding ath10k list to CC)

Erik Stromdahl <erik.stromdahl@gmail.com> writes:

>> Exactly what I was thinking. When I saw terms like "HTT" and "unified
>> WMI" my first thought was that is this actually an ath10k based design?
>> The product numbers really don't give any indication what driver
>> supports, the division goes something like this:
>>=20
>> * ath9k: "non-mobile" 11n chips
>> * ath6k: mobile 11n chips
>> * ath10k: mobile and "non-mobile" 11ac chips
>>=20
>> For example QCA6174 is an 11ac mobile chip supported by ath10k. ath10k
>> only supports PCI bus at the moment, but I'm hoping someone would add
>> USB and SDIO support. Patches are very welcome.
>>=20
>> I'm starting to suspect that QCA6584 is actually based on the same
>> design as QCA6174. If that's the case when we should also think if
>> instead we should add SDIO support to ath10k, maybe by taking relevant
>> parts from ath6kl?
>>=20
>> I'll investigate more what this QCA6584 is, I haven't heard about it
>> before.
>>=20
>
> The reason I have patched to ath6kl driver was that it is the
> only driver with sdio/mbox support.
>
> I was actually thinking of writing a new driver from scratch, but I
> thought that it was less work to modify the existing ath6kl driver.

Ok.

> I just haven't considered the option to add sdio/mbox support to ath10k.
> This is definitely something I will have a look at.
>
> I should mention that I have been using the qcacld2.0 driver as
> "documentation" of the chipset.
>
> The qcacld driver identifies the chipset as AR6320
>
> From the qcacld2.0 driver bmi_msg.h:
>
> #define TARGET_TYPE_AR6320    8
>
> Perhaps this can shed some light on what kind of chip this is?

I'm pretty sure that this is QCA6174 based design which is already
supported by ath10k. So my suggestion is to first look at adding SDIO
support to ath10k and see if that's feasible. We already have PCI code
split from the core code (ath10k_core.ko and ath10k_pci.ko) just because
I was expecting that we would add SDIO and USB support later. That has
just never happened due to lack of time, hopefully you can fix that now
;)

I haven't studied SDIO support at all yet but hopefully WMI, core.c and
mac.c won't need that much modifications. HTT and HTC most likely need
bigger changes. And then you would need to add sdio.c, similarly like we
have pci.c now. Keep in mind that later we might want to add USB support
also so if there's something which both SDIO and USB need to that would
need to be easily sharable. Actually after adding SDIO I hope USB would
be easier to add.

--=20
Kalle Valo=

Re: [RFC 0/5] ath6kl: non WMI data service support

[Valo, Kalle]

(Adding ath10k list to CC)

Erik Stromdahl <erik.stromdahl@gmail.com> writes:

>> Exactly what I was thinking. When I saw terms like "HTT" and "unified
>> WMI" my first thought was that is this actually an ath10k based design?
>> The product numbers really don't give any indication what driver
>> supports, the division goes something like this:
>> 
>> * ath9k: "non-mobile" 11n chips
>> * ath6k: mobile 11n chips
>> * ath10k: mobile and "non-mobile" 11ac chips
>> 
>> For example QCA6174 is an 11ac mobile chip supported by ath10k. ath10k
>> only supports PCI bus at the moment, but I'm hoping someone would add
>> USB and SDIO support. Patches are very welcome.
>> 
>> I'm starting to suspect that QCA6584 is actually based on the same
>> design as QCA6174. If that's the case when we should also think if
>> instead we should add SDIO support to ath10k, maybe by taking relevant
>> parts from ath6kl?
>> 
>> I'll investigate more what this QCA6584 is, I haven't heard about it
>> before.
>> 
>
> The reason I have patched to ath6kl driver was that it is the
> only driver with sdio/mbox support.
>
> I was actually thinking of writing a new driver from scratch, but I
> thought that it was less work to modify the existing ath6kl driver.

Ok.

> I just haven't considered the option to add sdio/mbox support to ath10k.
> This is definitely something I will have a look at.
>
> I should mention that I have been using the qcacld2.0 driver as
> "documentation" of the chipset.
>
> The qcacld driver identifies the chipset as AR6320
>
> From the qcacld2.0 driver bmi_msg.h:
>
> #define TARGET_TYPE_AR6320    8
>
> Perhaps this can shed some light on what kind of chip this is?

I'm pretty sure that this is QCA6174 based design which is already
supported by ath10k. So my suggestion is to first look at adding SDIO
support to ath10k and see if that's feasible. We already have PCI code
split from the core code (ath10k_core.ko and ath10k_pci.ko) just because
I was expecting that we would add SDIO and USB support later. That has
just never happened due to lack of time, hopefully you can fix that now
;)

I haven't studied SDIO support at all yet but hopefully WMI, core.c and
mac.c won't need that much modifications. HTT and HTC most likely need
bigger changes. And then you would need to add sdio.c, similarly like we
have pci.c now. Keep in mind that later we might want to add USB support
also so if there's something which both SDIO and USB need to that would
need to be easily sharable. Actually after adding SDIO I hope USB would
be easier to add.

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

Re: [RFC 0/5] ath6kl: non WMI data service support

[Valo, Kalle]

(Adding ath10k list)

Erik Stromdahl <erik.stromdahl@gmail.com> writes:

> On 10/14/2016 09:34 AM, Valo, Kalle wrote:
>> Erik Stromdahl <erik.stromdahl@gmail.com> writes:
>>=20
>>> This patch series is intended to prepare the ath6kl driver
>>> for newer chipsets that doesn't use the current WMI data
>>> endpoints for data traffic.
>>>
>>> The chipset I have been working with (and used for testing)
>>> is QCA6584. It is SDIO based (at least the variant I have
>>> been using) with 802.11p WAVE DSRC capabilities.
>>>
>>> This chipset is different from the AR600X family in that
>>> it does not use the WMI data services (service id's 0x101
>>> to 0x104 ) for data traffic.
>>> Instead it uses the HTT data service for data and wmi unified
>>> for control messages.
>>> It is also different when it comes to mailbox addresses
>>> and HTC header format as well, but these differences are not
>>> part of this patch series.
>>=20
>> Do you have more patches implemented, like something already working or
>> have just started?
>>=20
>
> I have an implementation with all features I need so far, but the other
> patches will require cleanup before I can submit anything.
>
> I have been using the qcacld driver as a basis for the work and some of
> the stuff in that driver is not really compliant with the kernel coding
> style (to say the least).
>
> I have so far mainly been focused on getting all features up and running
> and that has (unfortunately) resulted in some copy-pasting from
> qcacld.

Can you share the current code you have somewhere so that I could take a
quick look? I don't care how ugly it is, I would just like to understand
what kind of changes are needed.

> I will start having a look at ath10k and see how much work it would be
> to add sdio support to it...

Thanks, let me know how it goes or if I can help somehow. My time is
limited but if nothing else I can give some tips.

--=20
Kalle Valo=

Re: [RFC 0/5] ath6kl: non WMI data service support

[Valo, Kalle]

(Adding ath10k list)

Erik Stromdahl <erik.stromdahl@gmail.com> writes:

> On 10/14/2016 09:34 AM, Valo, Kalle wrote:
>> Erik Stromdahl <erik.stromdahl@gmail.com> writes:
>> 
>>> This patch series is intended to prepare the ath6kl driver
>>> for newer chipsets that doesn't use the current WMI data
>>> endpoints for data traffic.
>>>
>>> The chipset I have been working with (and used for testing)
>>> is QCA6584. It is SDIO based (at least the variant I have
>>> been using) with 802.11p WAVE DSRC capabilities.
>>>
>>> This chipset is different from the AR600X family in that
>>> it does not use the WMI data services (service id's 0x101
>>> to 0x104 ) for data traffic.
>>> Instead it uses the HTT data service for data and wmi unified
>>> for control messages.
>>> It is also different when it comes to mailbox addresses
>>> and HTC header format as well, but these differences are not
>>> part of this patch series.
>> 
>> Do you have more patches implemented, like something already working or
>> have just started?
>> 
>
> I have an implementation with all features I need so far, but the other
> patches will require cleanup before I can submit anything.
>
> I have been using the qcacld driver as a basis for the work and some of
> the stuff in that driver is not really compliant with the kernel coding
> style (to say the least).
>
> I have so far mainly been focused on getting all features up and running
> and that has (unfortunately) resulted in some copy-pasting from
> qcacld.

Can you share the current code you have somewhere so that I could take a
quick look? I don't care how ugly it is, I would just like to understand
what kind of changes are needed.

> I will start having a look at ath10k and see how much work it would be
> to add sdio support to it...

Thanks, let me know how it goes or if I can help somehow. My time is
limited but if nothing else I can give some tips.

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