linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sibi Sankar <sibis@codeaurora.org>
To: Stephen Boyd <swboyd@chromium.org>
Cc: bjorn.andersson@linaro.org, mka@chromium.org, robh+dt@kernel.org,
	ulf.hansson@linaro.org, rjw@rjwysocki.net, agross@kernel.org,
	ohad@wizery.com, mathieu.poirier@linaro.org,
	linux-arm-msm@vger.kernel.org, linux-remoteproc@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	dianders@chromium.org, rishabhb@codeaurora.org,
	sidgup@codeaurora.org
Subject: Re: [PATCH v4 04/13] remoteproc: qcom: q6v5: Use qmp_send to update co-processor load state
Date: Wed, 21 Jul 2021 22:57:20 +0530	[thread overview]
Message-ID: <a2c8d6e237e9b7f63ed1d3d4eda43ad8@codeaurora.org> (raw)
In-Reply-To: <CAE-0n518x-W8kCdtrLjw0kwsbEnLzk9OmnKara_B=et0j9+ScA@mail.gmail.com>

On 2021-07-21 10:56, Stephen Boyd wrote:
> Quoting Sibi Sankar (2021-07-19 21:36:38)
>> diff --git a/drivers/remoteproc/qcom_q6v5.c 
>> b/drivers/remoteproc/qcom_q6v5.c
>> index 7e9244c748da..997ff21271f7 100644
>> --- a/drivers/remoteproc/qcom_q6v5.c
>> +++ b/drivers/remoteproc/qcom_q6v5.c
>> @@ -16,8 +16,28 @@
>>  #include "qcom_common.h"
>>  #include "qcom_q6v5.h"
>> 
>> +#define Q6V5_LOAD_STATE_MSG_LEN        64
>>  #define Q6V5_PANIC_DELAY_MS    200
>> 
>> +static int q6v5_load_state_toggle(struct qcom_q6v5 *q6v5, bool 
>> enable)
>> +{
>> +       char buf[Q6V5_LOAD_STATE_MSG_LEN] = {};
> 
> Just to confirm, we want to set the whole buffer to zero before writing
> it? Sounds good to not send stack junk over to to the other side but
> maybe we could skip initializing to zero for the first part of the
> buffer that isn't used?

Sure, it makes sense to incorporate
a warn_on and memset the remainder
of the buffer after populating it.

> 
>> +       int ret;
>> +
>> +       if (IS_ERR(q6v5->qmp))
>> +               return 0;
>> +
>> +       snprintf(buf, sizeof(buf),
>> +                "{class: image, res: load_state, name: %s, val: %s}",
>> +                q6v5->load_state, enable ? "on" : "off");
> 
> Should we WARN_ON() if the message doesn't fit into the 64-bytes?
> 
>> +
>> +       ret = qmp_send(q6v5->qmp, buf, sizeof(buf));
>> +       if (ret)
>> +               dev_err(q6v5->dev, "failed to toggle load state\n");
>> +
>> +       return ret;
>> +}
>> +
>>  /**
>>   * qcom_q6v5_prepare() - reinitialize the qcom_q6v5 context before 
>> start
>>   * @q6v5:      reference to qcom_q6v5 context to be reinitialized
>> @@ -196,12 +223,13 @@ EXPORT_SYMBOL_GPL(qcom_q6v5_panic);
>>   * @pdev:      platform_device reference for acquiring resources
>>   * @rproc:     associated remoteproc instance
>>   * @crash_reason: SMEM id for crash reason string, or 0 if none
>> + * @load_state: load state resource string
>>   * @handover:  function to be called when proxy resources should be 
>> released
>>   *
>>   * Return: 0 on success, negative errno on failure
>>   */
>>  int qcom_q6v5_init(struct qcom_q6v5 *q6v5, struct platform_device 
>> *pdev,
>> -                  struct rproc *rproc, int crash_reason,
>> +                  struct rproc *rproc, int crash_reason, const char 
>> *load_state,
>>                    void (*handover)(struct qcom_q6v5 *q6v5))
>>  {
>>         int ret;
>> @@ -286,9 +314,36 @@ int qcom_q6v5_init(struct qcom_q6v5 *q6v5, struct 
>> platform_device *pdev,
>>                 return PTR_ERR(q6v5->state);
>>         }
>> 
>> +       q6v5->load_state = kstrdup_const(load_state, GFP_KERNEL);
>> +       q6v5->qmp = qmp_get(&pdev->dev);
>> +       if (IS_ERR(q6v5->qmp)) {
>> +               if (PTR_ERR(q6v5->qmp) != -ENODEV) {
>> +                       if (PTR_ERR(q6v5->qmp) != -EPROBE_DEFER)
>> +                               dev_err(&pdev->dev, "failed to acquire 
>> load state\n");
> 
> Use dev_err_probe()?

sure I'll use it.

> 
>> +                       kfree_const(q6v5->load_state);
>> +                       return PTR_ERR(q6v5->qmp);
>> +               }
>> +       } else {
>> +               if (!q6v5->load_state) {
> 
> Use else if and deindent?

lol, my bad.

> 
>> +                       dev_err(&pdev->dev, "load state resource 
>> string empty\n");
>> +                       return -EINVAL;
>> +               }
>> +       }
>> +
>>         return 0;
>>  }
>>  EXPORT_SYMBOL_GPL(qcom_q6v5_init);
>> 

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

  reply	other threads:[~2021-07-21 17:27 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-20  4:36 [PATCH v4 00/13] Use qmp_send to update co-processor load state Sibi Sankar
2021-07-20  4:36 ` [PATCH v4 01/13] dt-bindings: soc: qcom: aoss: Drop the load state power-domain Sibi Sankar
2021-07-20 21:10   ` Matthias Kaehlcke
2021-07-21  5:31   ` Stephen Boyd
2021-07-26 22:37   ` Rob Herring
2021-07-20  4:36 ` [PATCH v4 02/13] dt-bindings: remoteproc: qcom: pas: Add QMP property Sibi Sankar
2021-07-20 23:10   ` Matthias Kaehlcke
2021-07-21 16:58     ` Sibi Sankar
2021-07-20  4:36 ` [PATCH v4 03/13] dt-bindings: remoteproc: qcom: " Sibi Sankar
2021-07-20  4:36 ` [PATCH v4 04/13] remoteproc: qcom: q6v5: Use qmp_send to update co-processor load state Sibi Sankar
2021-07-21  5:26   ` Stephen Boyd
2021-07-21 17:27     ` Sibi Sankar [this message]
2021-07-30 16:36   ` Bjorn Andersson
2021-07-20  4:36 ` [PATCH v4 05/13] arm64: dts: qcom: sc7180: Use QMP property to control " Sibi Sankar
2021-07-20  4:36 ` [PATCH v4 06/13] arm64: dts: qcom: sc7280: " Sibi Sankar
2021-07-20  4:36 ` [PATCH v4 07/13] arm64: dts: qcom: sdm845: " Sibi Sankar
2021-07-20  4:36 ` [PATCH v4 08/13] arm64: dts: qcom: sm8150: " Sibi Sankar
2021-07-20  4:36 ` [PATCH v4 09/13] arm64: dts: qcom: sm8250: " Sibi Sankar
2021-07-20  4:36 ` [PATCH v4 10/13] arm64: dts: qcom: sm8350: " Sibi Sankar
2021-07-20  4:36 ` [PATCH v4 11/13] soc: qcom: aoss: Drop power domain support Sibi Sankar
2021-07-20 22:53   ` Matthias Kaehlcke
2021-07-21  5:35   ` Stephen Boyd
2021-07-20  4:36 ` [PATCH v4 12/13] dt-bindings: msm/dp: Remove aoss-qmp header Sibi Sankar
2021-07-21  5:16   ` Stephen Boyd
2021-07-20  4:36 ` [PATCH v4 13/13] dt-bindings: soc: qcom: aoss: Delete unused power-domain definitions Sibi Sankar

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=a2c8d6e237e9b7f63ed1d3d4eda43ad8@codeaurora.org \
    --to=sibis@codeaurora.org \
    --cc=agross@kernel.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dianders@chromium.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=mathieu.poirier@linaro.org \
    --cc=mka@chromium.org \
    --cc=ohad@wizery.com \
    --cc=rishabhb@codeaurora.org \
    --cc=rjw@rjwysocki.net \
    --cc=robh+dt@kernel.org \
    --cc=sidgup@codeaurora.org \
    --cc=swboyd@chromium.org \
    --cc=ulf.hansson@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).