From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Suman Anna <s-anna@ti.com>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>,
Lokesh Vutla <lokeshvutla@ti.com>,
Tero Kristo <kristo@kernel.org>,
linux-remoteproc@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/6] remoteproc: Introduce rproc_detach_device() wrapper
Date: Thu, 27 May 2021 23:17:57 -0500 [thread overview]
Message-ID: <YLBu9Wr1vNiwsfWT@builder.lan> (raw)
In-Reply-To: <20210522000309.26134-2-s-anna@ti.com>
On Fri 21 May 19:03 CDT 2021, Suman Anna wrote:
> The .attach() rproc ops is invoked through the helper
> rproc_attach_device(), but the .detach() ops is invoked
> directly at present. Introduce a similar wrapper function
> rproc_detach_device() for .detach() ops so that the code
> is symmetric.
>
> Signed-off-by: Suman Anna <s-anna@ti.com>
> ---
> drivers/remoteproc/remoteproc_core.c | 2 +-
> drivers/remoteproc/remoteproc_internal.h | 8 ++++++++
> 2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
> index 6348aaa42bbb..6019f46001c8 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -1869,7 +1869,7 @@ static int __rproc_detach(struct rproc *rproc)
> }
>
> /* Tell the remote processor the core isn't available anymore */
> - ret = rproc->ops->detach(rproc);
> + ret = rproc_detach_device(rproc);
> if (ret) {
> dev_err(dev, "can't detach from rproc: %d\n", ret);
> return ret;
> diff --git a/drivers/remoteproc/remoteproc_internal.h b/drivers/remoteproc/remoteproc_internal.h
> index a328e634b1de..931d50b6a0d1 100644
> --- a/drivers/remoteproc/remoteproc_internal.h
> +++ b/drivers/remoteproc/remoteproc_internal.h
> @@ -121,6 +121,14 @@ static inline int rproc_attach_device(struct rproc *rproc)
> return 0;
> }
>
> +static inline int rproc_detach_device(struct rproc *rproc)
> +{
> + if (rproc->ops->detach)
> + return rproc->ops->detach(rproc);
> +
> + return 0;
I was going to complain that this will silently succeed to detach a
remoteproc when the driver doesn't implement detach, but then I realized
that in the current code path we just failed if it wasn't set.
So this only becomes a problem if we're out of sync between the wish to
detach and the implementation of detach, in the later patch.
But based on this, why do we allow rproc_attach_device() to succeed even
though a driver doesn't implement attach? Could we achieve the symmetry
by going the other way?
Regards,
Bjorn
> +}
> +
> static inline
> int rproc_fw_sanity_check(struct rproc *rproc, const struct firmware *fw)
> {
> --
> 2.30.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-05-28 4:19 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-22 0:03 [PATCH 0/6] K3 R5F & DSP IPC-only mode support Suman Anna
2021-05-22 0:03 ` [PATCH 1/6] remoteproc: Introduce rproc_detach_device() wrapper Suman Anna
2021-05-28 4:17 ` Bjorn Andersson [this message]
2021-05-28 16:17 ` Suman Anna
2021-05-22 0:03 ` [PATCH 2/6] remoteproc: Add support for detach-only during shutdown Suman Anna
2021-05-28 4:11 ` Bjorn Andersson
2021-05-28 16:40 ` Suman Anna
2021-06-01 17:15 ` Mathieu Poirier
2021-05-22 0:03 ` [PATCH 3/6] remoteproc: k3-r5: Refactor mbox request code in start Suman Anna
2021-06-01 17:22 ` Mathieu Poirier
2021-05-22 0:03 ` [PATCH 4/6] remoteproc: k3-r5: Add support for IPC-only mode for all R5Fs Suman Anna
2021-06-01 17:51 ` Mathieu Poirier
2021-06-02 15:53 ` Mathieu Poirier
2021-05-22 0:03 ` [PATCH 5/6] remoteproc: k3-dsp: Refactor mbox request code in start Suman Anna
2021-06-02 16:04 ` Mathieu Poirier
2021-05-22 0:03 ` [PATCH 6/6] remoteproc: k3-dsp: Add support for IPC-only mode for all K3 DSPs Suman Anna
2021-05-28 4:36 ` Bjorn Andersson
2021-05-28 17:04 ` Suman Anna
2021-06-02 16:07 ` Mathieu Poirier
2021-06-03 14:57 ` Suman Anna
2021-06-07 16:33 ` Mathieu Poirier
2021-06-16 15:00 ` Suman Anna
2021-06-22 22:51 ` Mathieu Poirier
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=YLBu9Wr1vNiwsfWT@builder.lan \
--to=bjorn.andersson@linaro.org \
--cc=kristo@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=lokeshvutla@ti.com \
--cc=mathieu.poirier@linaro.org \
--cc=s-anna@ti.com \
/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).