All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: ohad@wizery.com, linux-remoteproc@vger.kernel.org,
	linux-kernel@vger.kernel.org, loic.pallardy@st.com,
	arnaud.pouliquen@st.com, s-anna@ti.com
Subject: Re: [PATCH v4 9/9] remoteproc: Properly handle firmware name when attaching
Date: Tue, 23 Jun 2020 13:48:49 -0600	[thread overview]
Message-ID: <20200623194849.GC1908098@xps15> (raw)
In-Reply-To: <20200622073319.GK149351@builder.lan>

On Mon, Jun 22, 2020 at 12:33:19AM -0700, Bjorn Andersson wrote:
> On Mon 01 Jun 10:51 PDT 2020, Mathieu Poirier wrote:
> 
> > This patch prevents the firmware image name from being displayed when
> > the remoteproc core is attaching to a remote processor. This is needed
> > needed since there is no guarantee about the nature of the firmware
> > image that is loaded by the external entity.
> > 
> > Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> 
> How about renaming the bool "firmware_unknown"?

My hope was to use the same variable, i.e "autonomous", for the RUNNING ->
DETACHED and CRASHED -> DETACHED scenarios to reduce the amount of
variables we need to keep track of when the functionality is implemented in
upcoming pachsets.

Thanks for the review,
Mathieu

> 
> Apart from that, I think this looks good.
> 
> Regards,
> Bjorn
> 
> > ---
> >  drivers/remoteproc/remoteproc_core.c  | 18 ++++++++++++++++++
> >  drivers/remoteproc/remoteproc_sysfs.c | 16 ++++++++++++++--
> >  include/linux/remoteproc.h            |  2 ++
> >  3 files changed, 34 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
> > index 0e23284fbd25..a8adc712e7f6 100644
> > --- a/drivers/remoteproc/remoteproc_core.c
> > +++ b/drivers/remoteproc/remoteproc_core.c
> > @@ -1642,6 +1642,14 @@ static int rproc_stop(struct rproc *rproc, bool crashed)
> >  
> >  	rproc->state = RPROC_OFFLINE;
> >  
> > +	/*
> > +	 * The remote processor has been stopped and is now offline, which means
> > +	 * that the next time it is brought back online the remoteproc core will
> > +	 * be responsible to load its firmware.  As such it is no longer
> > +	 * autonomous.
> > +	 */
> > +	rproc->autonomous = false;
> > +
> >  	dev_info(dev, "stopped remote processor %s\n", rproc->name);
> >  
> >  	return 0;
> > @@ -2166,6 +2174,16 @@ int rproc_add(struct rproc *rproc)
> >  	/* create debugfs entries */
> >  	rproc_create_debug_dir(rproc);
> >  
> > +	/*
> > +	 * Remind ourselves the remote processor has been attached to rather
> > +	 * than booted by the remoteproc core.  This is important because the
> > +	 * RPROC_DETACHED state will be lost as soon as the remote processor
> > +	 * has been attached to.  Used in firmware_show() and reset in
> > +	 * rproc_stop().
> > +	 */
> > +	if (rproc->state == RPROC_DETACHED)
> > +		rproc->autonomous = true;
> > +
> >  	/* if rproc is marked always-on, request it to boot */
> >  	if (rproc->auto_boot) {
> >  		ret = rproc_trigger_auto_boot(rproc);
> > diff --git a/drivers/remoteproc/remoteproc_sysfs.c b/drivers/remoteproc/remoteproc_sysfs.c
> > index 8b462c501465..4ee158431f67 100644
> > --- a/drivers/remoteproc/remoteproc_sysfs.c
> > +++ b/drivers/remoteproc/remoteproc_sysfs.c
> > @@ -14,8 +14,20 @@ static ssize_t firmware_show(struct device *dev, struct device_attribute *attr,
> >  			  char *buf)
> >  {
> >  	struct rproc *rproc = to_rproc(dev);
> > -
> > -	return sprintf(buf, "%s\n", rproc->firmware);
> > +	const char *firmware = rproc->firmware;
> > +
> > +	/*
> > +	 * If the remote processor has been started by an external
> > +	 * entity we have no idea of what image it is running.  As such
> > +	 * simply display a generic string rather then rproc->firmware.
> > +	 *
> > +	 * Here we rely on the autonomous flag because a remote processor
> > +	 * may have been attached to and currently in a running state.
> > +	 */
> > +	if (rproc->autonomous)
> > +		firmware = "unknown";
> > +
> > +	return sprintf(buf, "%s\n", firmware);
> >  }
> >  
> >  /* Change firmware name via sysfs */
> > diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
> > index bf6a310ba870..cf5e31556780 100644
> > --- a/include/linux/remoteproc.h
> > +++ b/include/linux/remoteproc.h
> > @@ -491,6 +491,7 @@ struct rproc_dump_segment {
> >   * @table_sz: size of @cached_table
> >   * @has_iommu: flag to indicate if remote processor is behind an MMU
> >   * @auto_boot: flag to indicate if remote processor should be auto-started
> > + * @autonomous: true if an external entity has booted the remote processor
> >   * @dump_segments: list of segments in the firmware
> >   * @nb_vdev: number of vdev currently handled by rproc
> >   */
> > @@ -524,6 +525,7 @@ struct rproc {
> >  	size_t table_sz;
> >  	bool has_iommu;
> >  	bool auto_boot;
> > +	bool autonomous;
> >  	struct list_head dump_segments;
> >  	int nb_vdev;
> >  	u8 elf_class;
> > -- 
> > 2.20.1
> > 

  reply	other threads:[~2020-06-23 19:48 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-01 17:51 [PATCH v4 0/9] remoteproc: Add support for attaching with rproc Mathieu Poirier
2020-06-01 17:51 ` [PATCH v4 1/9] remoteproc: Add new RPROC_DETACHED state Mathieu Poirier
2020-06-22  6:25   ` Bjorn Andersson
2020-06-01 17:51 ` [PATCH v4 2/9] remoteproc: Add new attach() remoteproc operation Mathieu Poirier
2020-06-22  6:36   ` Bjorn Andersson
2020-06-01 17:51 ` [PATCH v4 3/9] remoteproc: Introducing function rproc_attach() Mathieu Poirier
2020-06-22  7:07   ` Bjorn Andersson
2020-06-22  7:18     ` Bjorn Andersson
2020-06-23 19:37       ` Mathieu Poirier
2020-06-01 17:51 ` [PATCH v4 4/9] remoteproc: Introducing function rproc_actuate() Mathieu Poirier
2020-06-22  7:18   ` Bjorn Andersson
2020-06-01 17:51 ` [PATCH v4 5/9] remoteproc: Introducing function rproc_validate() Mathieu Poirier
2020-06-22  7:25   ` Bjorn Andersson
2020-06-23 19:38     ` Mathieu Poirier
2020-06-01 17:51 ` [PATCH v4 6/9] remoteproc: Refactor function rproc_boot() Mathieu Poirier
2020-06-22  7:25   ` Bjorn Andersson
2020-06-01 17:51 ` [PATCH v4 7/9] remoteproc: Refactor function rproc_trigger_auto_boot() Mathieu Poirier
2020-06-22  7:25   ` Bjorn Andersson
2020-06-01 17:51 ` [PATCH v4 8/9] remoteproc: Refactor function rproc_free_vring() Mathieu Poirier
2020-06-22  7:27   ` Bjorn Andersson
2020-06-01 17:51 ` [PATCH v4 9/9] remoteproc: Properly handle firmware name when attaching Mathieu Poirier
2020-06-04 14:16   ` Arnaud POULIQUEN
2020-06-04 20:14     ` Mathieu Poirier
2020-06-22  7:33   ` Bjorn Andersson
2020-06-23 19:48     ` Mathieu Poirier [this message]
2020-06-23 20:09       ` Bjorn Andersson
2020-06-04 14:24 ` [PATCH v4 0/9] remoteproc: Add support for attaching with rproc Arnaud POULIQUEN
2020-06-04 20:27   ` 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=20200623194849.GC1908098@xps15 \
    --to=mathieu.poirier@linaro.org \
    --cc=arnaud.pouliquen@st.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=loic.pallardy@st.com \
    --cc=ohad@wizery.com \
    --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 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.