From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Cc: Andy Gross <andy.gross@linaro.org>,
Ohad Ben-Cohen <ohad@wizery.com>,
Arun Kumar Neelakantam <aneela@codeaurora.org>,
Chris Lew <clew@codeaurora.org>,
linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-soc@vger.kernel.org, linux-remoteproc@vger.kernel.org
Subject: Re: [PATCH v3 2/5] soc: qcom: Introduce QMI helpers
Date: Thu, 16 Nov 2017 22:30:54 -0800 [thread overview]
Message-ID: <20171117063054.GT28761@minitux> (raw)
In-Reply-To: <f4dbc5f7-04aa-b493-da22-2a8df465496b@linaro.org>
On Thu 16 Nov 04:11 PST 2017, Srinivas Kandagatla wrote:
> On 15/11/17 20:10, Bjorn Andersson wrote:
[..]
> > diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
> > index 91b70b170a82..9718f1c41e3d 100644
> > --- a/drivers/soc/qcom/Kconfig
> > +++ b/drivers/soc/qcom/Kconfig
> > @@ -37,6 +37,7 @@ config QCOM_PM
> > config QCOM_QMI_HELPERS
> > tristate
> > + depends on ARCH_QCOM
>
> This bit is confusing!!, first patch added this symbol and this patch added
> the depends. either we move this to first patch or move out the
> QCOM_QMI_HELPERS from first patch and include in this patch
>
Ohh, that's not right. The depends should be in the same patch.
And we don't really depends on ARCH_QCOM here, but without it Kconfig
doesn't know that make won't enter drivers/soc/qcom so we will end up
with a link error. I'm hoping we can fix this issue, to get some more
compile testing of these things.
> > help
> > Helper library for handling QMI encoded messages. QMI encoded
> > messages are used in communication between the majority of QRTR
> > diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
[..]
> > obj-$(CONFIG_QCOM_QMI_HELPERS) += qmi_helpers.o
> > qmi_helpers-y += qmi_encdec.o
> > +qmi_helpers-y += qmi_interface.o
> for better reading.. i would suggest..
> qmi_helpers-y += qmi_encdec.o qmi_interface.o
>
Sounds reasonable.
>
> > obj-$(CONFIG_QCOM_SMD_RPM) += smd-rpm.o
> > obj-$(CONFIG_QCOM_SMEM) += smem.o
> > obj-$(CONFIG_QCOM_SMEM_STATE) += smem_state.o
> > diff --git a/drivers/soc/qcom/qmi_interface.c b/drivers/soc/qcom/qmi_interface.c
[..]
> > +#include <linux/platform_device.h>
>
> Do we need this?
>
I don't think so.
[..]
> > +/**
> > + * qmi_recv_new_server() - handler of NEW_SERVER control message
> > + * @qmi: qmi handle
> > + * @node: node of the new server
> > + * @port: port of the new server
> > + *
> service and instance is not documented here.
>
Thanks for noticing, will fix these.
[..]
> > +/**
> > + * qmi_handle_init() - initialize a QMI client handle
> > + * @qmi: QMI handle to initialize
> > + * @max_msg_len: maximum size of incoming message
> do we need this??
>
We need a buffer into which we can receive incoming packets, so either
we allocate a large enough buffer up front or we have to ask qrtr before
each packet how much space we will need.
I think largest possible buffer is 64kB, but typically we need much
less. And the IDL compiler seems to output this constant, so it seems
reasonable to pass it here.
>
> > + * @handlers: NULL-terminated list of QMI message handlers
> > + *
> recv_buf_size and ops not documented
>
Looks like I've renamed max_msg_len to recv_buf_size, and forgot to add
ops. Will fix.
[..]
> > +
> > +/**
> > + * qmi_send_indication() - send an indication QMI message
> > + * @qmi: QMI client handle
> > + * @sq: destination sockaddr
> > + * @txn: transaction object to use for the message
>
> txn is not required here?
>
No. Indications are fire-and-forget messages, but still need a
transaction id, so it's confusing for the client to have to create a
txn, use it and then cancel it (or to add another txn operation for
this). Therefor I'm hiding the txn handling inside this function.
Will fix the kerneldoc.
[..]
> > diff --git a/include/linux/soc/qcom/qmi.h b/include/linux/soc/qcom/qmi.h
> > index 5df7edfc6bfd..9b4f4fa5bed6 100644
> > --- a/include/linux/soc/qcom/qmi.h
> > +++ b/include/linux/soc/qcom/qmi.h
>
> Looks like this patch added few things like list, wq and so to this header
> file, should we not add headers for those ??
>
Will review these.
Thanks for the review!
Regards,
Bjorn
next prev parent reply other threads:[~2017-11-17 6:30 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-15 20:10 [PATCH v3 0/5] In-kernel QMI helpers and sysmon Bjorn Andersson
2017-11-15 20:10 ` [PATCH v3 1/5] soc: qcom: Introduce QMI encoder/decoder Bjorn Andersson
2017-11-16 5:42 ` Bjorn Andersson
2017-11-16 18:57 ` Chris Lew
2017-11-16 12:10 ` Srinivas Kandagatla
2017-11-17 6:10 ` Bjorn Andersson
2017-11-15 20:10 ` [PATCH v3 2/5] soc: qcom: Introduce QMI helpers Bjorn Andersson
2017-11-16 12:11 ` Srinivas Kandagatla
2017-11-17 6:30 ` Bjorn Andersson [this message]
2017-11-18 2:11 ` Chris Lew
2017-11-21 22:42 ` Bjorn Andersson
2017-11-15 20:10 ` [PATCH v3 3/5] remoteproc: Pass type of shutdown to subdev remove Bjorn Andersson
2017-11-15 20:10 ` [PATCH v3 4/5] remoteproc: qcom: Introduce sysmon Bjorn Andersson
2017-11-16 20:05 ` Chris Lew
2017-11-17 5:58 ` Bjorn Andersson
2017-11-18 1:27 ` Chris Lew
2017-11-15 20:10 ` [PATCH v3 5/5] samples: Introduce Qualcomm QMI sample client Bjorn Andersson
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=20171117063054.GT28761@minitux \
--to=bjorn.andersson@linaro.org \
--cc=andy.gross@linaro.org \
--cc=aneela@codeaurora.org \
--cc=clew@codeaurora.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=linux-soc@vger.kernel.org \
--cc=ohad@wizery.com \
--cc=srinivas.kandagatla@linaro.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.