From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Govind Singh <govinds@codeaurora.org>
Cc: ath10k@lists.infradead.org, linux-wireless@vger.kernel.org
Subject: Re: [PATCH 08/12] ath10k: Add QMI CAP request support
Date: Fri, 11 May 2018 11:52:23 -0700 [thread overview]
Message-ID: <20180511185223.GS2259@tuxbook-pro> (raw)
In-Reply-To: <1522042847-26245-1-git-send-email-govinds@codeaurora.org>
On Sun 25 Mar 22:40 PDT 2018, Govind Singh wrote:
> Add support for target capablity request
> qmi message for wcn3990 target.
>
> Signed-off-by: Govind Singh <govinds@codeaurora.org>
> ---
> drivers/net/wireless/ath/ath10k/qmi.c | 91 +++++++++++++++++++++++++++++++++++
> drivers/net/wireless/ath/ath10k/qmi.h | 25 ++++++++++
> 2 files changed, 116 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ath10k/qmi.c b/drivers/net/wireless/ath/ath10k/qmi.c
> index 763b812..65a43af 100644
> --- a/drivers/net/wireless/ath/ath10k/qmi.c
> +++ b/drivers/net/wireless/ath/ath10k/qmi.c
> @@ -270,6 +270,93 @@ static int ath10k_qmi_msa_ready_send_sync_msg(struct ath10k_qmi *qmi)
> return ret;
> }
>
> +static int ath10k_qmi_cap_send_sync_msg(struct ath10k_qmi *qmi)
> +{
> + struct wlfw_cap_resp_msg_v01 *resp;
I think this is 207 bytes, so it makes sense to allocate this on the
heap.
> + struct wlfw_cap_req_msg_v01 *req;
But this is 1 bytes, so keep it on the stack.
> + struct qmi_txn txn;
> + int ret;
> +
> + req = kzalloc(sizeof(*req), GFP_KERNEL);
> + if (!req)
> + return -ENOMEM;
> +
> + resp = kzalloc(sizeof(*resp), GFP_KERNEL);
> + if (!resp) {
> + kfree(req);
> + return -ENOMEM;
> + }
> +
> + ret = qmi_txn_init(&qmi->qmi_hdl, &txn, wlfw_cap_resp_msg_v01_ei, resp);
> + if (ret < 0) {
> + pr_err("fail to init txn for capability resp %d\n", ret);
Same comments as in previous patches.
> + goto out;
> + }
> +
> + ret = qmi_send_request(&qmi->qmi_hdl, NULL, &txn,
> + QMI_WLFW_CAP_REQ_V01,
> + WLFW_CAP_REQ_MSG_V01_MAX_MSG_LEN,
> + wlfw_cap_req_msg_v01_ei, req);
> + if (ret < 0) {
> + qmi_txn_cancel(&txn);
> + pr_err("fail to send capability req %d\n", ret);
> + goto out;
> + }
> +
> + ret = qmi_txn_wait(&txn, WLFW_TIMEOUT * HZ);
> + if (ret < 0)
> + goto out;
> +
> + if (resp->resp.result != QMI_RESULT_SUCCESS_V01) {
> + pr_err("qmi capability request rejected, result:%d error:%d\n",
> + resp->resp.result, resp->resp.error);
> + ret = -resp->resp.result;
> + goto out;
> + }
> +
> + if (resp->chip_info_valid) {
> + qmi->chip_info.chip_id = resp->chip_info.chip_id;
> + qmi->chip_info.chip_family = resp->chip_info.chip_family;
> + }
> +
> + if (resp->board_info_valid)
> + qmi->board_info.board_id = resp->board_info.board_id;
> + else
> + qmi->board_info.board_id = 0xFF;
> +
> + if (resp->soc_info_valid)
> + qmi->soc_info.soc_id = resp->soc_info.soc_id;
> +
> + if (resp->fw_version_info_valid) {
> + qmi->fw_version_info.fw_version =
> + resp->fw_version_info.fw_version;
> + strlcpy(qmi->fw_version_info.fw_build_timestamp,
> + resp->fw_version_info.fw_build_timestamp,
> + MAX_TIMESTAMP_LEN + 1);
Use sizeof(qmi->fw_version_info.fw_build_timestamp) to remove the risk
of them getting out of sync.
> + }
> +
> + if (resp->fw_build_id_valid)
> + strlcpy(qmi->fw_build_id, resp->fw_build_id,
> + MAX_BUILD_ID_LEN + 1);
> +
> + pr_debug("chip_id: 0x%x, chip_family: 0x%x, board_id: 0x%x, soc_id: 0x%x, fw_version: 0x%x, fw_build_timestamp: %s, fw_build_id: %s",
> + qmi->chip_info.chip_id, qmi->chip_info.chip_family,
> + qmi->board_info.board_id, qmi->soc_info.soc_id,
> + qmi->fw_version_info.fw_version,
> + qmi->fw_version_info.fw_build_timestamp,
> + qmi->fw_build_id);
Use dev_dbg(), but perhaps this could even be a dev_info()?
> +
> + pr_debug("target cap request completed\n");
> + kfree(resp);
> + kfree(req);
> +
> + return 0;
> +out:
> + kfree(resp);
> + kfree(req);
> + return ret;
> +}
> +
> static int
> ath10k_qmi_ind_register_send_sync_msg(struct ath10k_qmi *qmi)
> {
> @@ -425,6 +512,10 @@ static void ath10k_qmi_event_server_arrive(struct work_struct *work)
> if (ret)
> goto err_setup_msa;
>
> + ret = ath10k_qmi_cap_send_sync_msg(qmi);
> + if (ret)
> + goto err_setup_msa;
> +
> return;
>
> err_setup_msa:
> diff --git a/drivers/net/wireless/ath/ath10k/qmi.h b/drivers/net/wireless/ath/ath10k/qmi.h
> index 47af020..09d20a0 100644
> --- a/drivers/net/wireless/ath/ath10k/qmi.h
> +++ b/drivers/net/wireless/ath/ath10k/qmi.h
> @@ -17,6 +17,8 @@
> #define _QMI_H_
>
> #define MAX_NUM_MEMORY_REGIONS 2
> +#define MAX_TIMESTAMP_LEN 32
> +#define MAX_BUILD_ID_LEN 128
>
> enum ath10k_qmi_driver_event_type {
> ATH10K_QMI_EVENT_SERVER_ARRIVE,
> @@ -31,6 +33,24 @@ struct ath10k_msa_mem_region_info {
> u8 secure_flag;
> };
>
> +struct ath10k_qmi_chip_info {
> + u32 chip_id;
> + u32 chip_family;
> +};
> +
> +struct ath10k_qmi_board_info {
> + u32 board_id;
> +};
> +
> +struct ath10k_qmi_soc_info {
> + u32 soc_id;
> +};
> +
> +struct ath10k_qmi_fw_version_info {
> + u32 fw_version;
> + char fw_build_timestamp[MAX_TIMESTAMP_LEN + 1];
> +};
I don't see the benefit off lugging these around as separate structs,
why not just put them in the ath10k_qmi struct directly.
But in particular, I don't see a reason for stashing the data that will
never be used, store the parts that you're actually using.
> +
> struct ath10k_qmi {
> struct platform_device *pdev;
> struct qmi_handle qmi_hdl;
> @@ -47,5 +67,10 @@ struct ath10k_qmi {
> phys_addr_t msa_pa;
> u32 msa_mem_size;
> void *msa_va;
> + struct ath10k_qmi_chip_info chip_info;
> + struct ath10k_qmi_board_info board_info;
> + struct ath10k_qmi_soc_info soc_info;
> + struct ath10k_qmi_fw_version_info fw_version_info;
> + char fw_build_id[MAX_BUILD_ID_LEN + 1];
> };
> #endif /* _QMI_H_ */
Regards,
Bjorn
prev parent reply other threads:[~2018-05-11 18:51 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-26 5:40 [PATCH 08/12] ath10k: Add QMI CAP request support Govind Singh
2018-05-11 18:52 ` Bjorn Andersson [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180511185223.GS2259@tuxbook-pro \
--to=bjorn.andersson@linaro.org \
--cc=ath10k@lists.infradead.org \
--cc=govinds@codeaurora.org \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox