All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Arnaud POULIQUEN <arnaud.pouliquen@st.com>
Cc: bjorn.andersson@linaro.org, ohad@wizery.com,
	loic.pallardy@st.com, s-anna@ti.com,
	linux-remoteproc@vger.kernel.org, corbet@lwn.net,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 11/14] remoteproc: Deal with synchronisation when changing FW image
Date: Thu, 30 Apr 2020 14:32:05 -0600	[thread overview]
Message-ID: <20200430203205.GA18004@xps15> (raw)
In-Reply-To: <4ab6d7ac-905b-494e-cce7-cb8a697decb7@st.com>

On Wed, Apr 29, 2020 at 10:52:48AM +0200, Arnaud POULIQUEN wrote:
> 
> 
> On 4/24/20 10:01 PM, Mathieu Poirier wrote:
> > This patch prevents the firmware image from being displayed or changed
> > when the remoteproc core is synchronising with a remote processor. This
> > is 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>
> > ---
> >  drivers/remoteproc/remoteproc_sysfs.c | 24 +++++++++++++++++++++++-
> >  1 file changed, 23 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/remoteproc/remoteproc_sysfs.c b/drivers/remoteproc/remoteproc_sysfs.c
> > index 7f8536b73295..cdd322a6ecfa 100644
> > --- a/drivers/remoteproc/remoteproc_sysfs.c
> > +++ b/drivers/remoteproc/remoteproc_sysfs.c
> > @@ -13,9 +13,20 @@
> >  static ssize_t firmware_show(struct device *dev, struct device_attribute *attr,
> >  			  char *buf)
> >  {
> > +	ssize_t ret;
> >  	struct rproc *rproc = to_rproc(dev);
> >  
> > -	return sprintf(buf, "%s\n", rproc->firmware);
> > +	/*
> > +	 * In most instances there is no guarantee about the firmware
> > +	 * that was loaded by the external entity.  As such simply don't
> > +	 * print anything.
> > +	 */
> > +	if (rproc_needs_syncing(rproc))
> > +		ret = sprintf(buf, "\n");
> 
> A default name is provided in sysfs if no firmware is started/synchronised on boot.
> 
> IMO providing an empty name here could be confusing.
> Perhaps a refactoring of this sysfs entry would be nice:
>  - Normal boot (no firmware loaded) : empty name instead of a default name

That is guaranteed to break user space so we can't proceed this way.

>  - auto_boot: name provided by the platform driver or default name ( current implementation)
>  - synchronization: a predefined name such as Default, unknown, External, None,...   

Loic had the same comment.  Usually it is best to provide sysfs output that
don't need parsing, i.e 0/1 or nothing at all, but in the remoteproc subsystem
we already have "state", "name" and "firmware" that need parsing.  As such my
next revision will have "unknown", which I think is the best way to describe the
situation.

> 
> > +	else
> > +		ret = sprintf(buf, "%s\n", rproc->firmware);
> > +
> > +	return ret;
> >  }
> >  
> >  /* Change firmware name via sysfs */
> > @@ -39,6 +50,17 @@ static ssize_t firmware_store(struct device *dev,
> >  		goto out;
> >  	}
> >  
> > +	/*
> > +	 * There is no point in trying to change the firmware if loading the
> > +	 * image of the remote processor is done by another entity.
> > +	 */
> > +	if (rproc_needs_syncing(rproc)) {
> > +		dev_err(dev,
> > +			"can't change firmware while synchronising with MCU\n");
> 
> I don't know if you decide to keep "MCU" or not. If not the case
> you have also some other instances in your patch 9/14.

MCU should be long gone.  I thought I had spotted them all but was obviously
wrong.

> 
> Regards
> Arnaud
> 
> > +		err = -EBUSY;
> > +		goto out;
> > +	}
> > +
> >  	len = strcspn(buf, "\n");
> >  	if (!len) {
> >  		dev_err(dev, "can't provide a NULL firmware\n");
> > 

  reply	other threads:[~2020-04-30 20:32 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-24 20:01 [PATCH v3 00/14] remoteproc: Add support for synchronisaton with rproc Mathieu Poirier
2020-04-24 20:01 ` [PATCH v3 01/14] remoteproc: Make core operations optional Mathieu Poirier
2020-04-28 16:18   ` Arnaud POULIQUEN
2020-04-30 19:39     ` Mathieu Poirier
2020-05-05 22:16   ` Bjorn Andersson
2020-05-08 19:09     ` Mathieu Poirier
2020-04-24 20:01 ` [PATCH v3 02/14] remoteproc: Introduce function rproc_alloc_internals() Mathieu Poirier
2020-05-05 22:31   ` Bjorn Andersson
2020-05-08 19:37     ` Mathieu Poirier
2020-04-24 20:01 ` [PATCH v3 03/14] remoteproc: Add new operation and flags for synchronistation Mathieu Poirier
2020-04-28 16:38   ` Arnaud POULIQUEN
2020-04-30 19:49     ` Mathieu Poirier
2020-05-06  0:22   ` Bjorn Andersson
2020-05-08 21:01     ` Mathieu Poirier
2020-05-14  1:32       ` Bjorn Andersson
2020-05-15 19:24         ` Mathieu Poirier
2020-05-19  0:55           ` Bjorn Andersson
2020-05-20 22:06             ` Mathieu Poirier
2020-05-21  5:21               ` Bjorn Andersson
2020-05-21 21:55                 ` Mathieu Poirier
2020-04-24 20:01 ` [PATCH v3 04/14] remoteproc: Refactor function rproc_boot() Mathieu Poirier
2020-04-24 20:01 ` [PATCH v3 05/14] remoteproc: Refactor function rproc_fw_boot() Mathieu Poirier
2020-05-06  0:33   ` Bjorn Andersson
2020-05-08 21:27     ` Mathieu Poirier
2020-05-14  2:10       ` Bjorn Andersson
2020-05-15 19:46         ` Mathieu Poirier
2020-05-19  0:22           ` Bjorn Andersson
2020-04-24 20:01 ` [PATCH v3 06/14] remoteproc: Refactor function rproc_trigger_auto_boot() Mathieu Poirier
2020-04-28 17:00   ` Arnaud POULIQUEN
2020-04-24 20:01 ` [PATCH v3 07/14] remoteproc: Introducting new start and stop functions Mathieu Poirier
2020-05-06  0:42   ` Bjorn Andersson
2020-04-24 20:01 ` [PATCH v3 08/14] remoteproc: Call core functions based on synchronisation flag Mathieu Poirier
2020-04-28 17:27   ` Arnaud POULIQUEN
2020-04-30 19:57     ` Mathieu Poirier
2020-05-04 11:14       ` Arnaud POULIQUEN
2020-05-05 22:10         ` Mathieu Poirier
2020-04-24 20:01 ` [PATCH v3 09/14] remoteproc: Deal with synchronisation when crashing Mathieu Poirier
2020-04-29  7:44   ` Arnaud POULIQUEN
2020-04-30 20:11     ` Mathieu Poirier
2020-05-06  1:01   ` Bjorn Andersson
2020-05-08 21:47     ` Mathieu Poirier
2020-04-24 20:01 ` [PATCH v3 10/14] remoteproc: Deal with synchronisation when shutting down Mathieu Poirier
2020-04-29  8:19   ` Arnaud POULIQUEN
2020-04-30 20:23     ` Mathieu Poirier
2020-05-04 11:34       ` Arnaud POULIQUEN
2020-05-05 22:03         ` Mathieu Poirier
2020-05-06  7:51           ` Arnaud POULIQUEN
2020-05-06  1:10   ` Bjorn Andersson
2020-04-24 20:01 ` [PATCH v3 11/14] remoteproc: Deal with synchronisation when changing FW image Mathieu Poirier
2020-04-29  8:52   ` Arnaud POULIQUEN
2020-04-30 20:32     ` Mathieu Poirier [this message]
2020-05-06  1:27   ` Bjorn Andersson
2020-04-24 20:01 ` [PATCH v3 12/14] remoteproc: Introducing function rproc_set_state_machine() Mathieu Poirier
2020-04-29  9:22   ` Arnaud POULIQUEN
2020-04-29 14:38     ` Arnaud POULIQUEN
2020-04-30 20:51       ` Mathieu Poirier
2020-05-04 12:00         ` Arnaud POULIQUEN
2020-04-30 20:42     ` Mathieu Poirier
2020-05-04 11:57       ` Arnaud POULIQUEN
2020-05-05 21:43         ` Mathieu Poirier
2020-04-24 20:01 ` [PATCH v3 13/14] remoteproc: Document " Mathieu Poirier
2020-04-24 20:01 ` [PATCH v3 14/14] remoteproc: Expose synchronisation flags via debugfs Mathieu Poirier
2020-05-18 13:28 ` [PATCH v3 00/14] remoteproc: Add support for synchronisaton with rproc Peng Fan
2020-05-18 16:29   ` 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=20200430203205.GA18004@xps15 \
    --to=mathieu.poirier@linaro.org \
    --cc=arnaud.pouliquen@st.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=corbet@lwn.net \
    --cc=linux-doc@vger.kernel.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.