All of lore.kernel.org
 help / color / mirror / Atom feed
From: f.fainelli@gmail.com (Florian Fainelli)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 4/4] remoteproc: debugfs: Add ability to boot remote processor using debugfs
Date: Fri, 28 Aug 2015 10:17:28 -0700	[thread overview]
Message-ID: <55E097A8.4080305@gmail.com> (raw)
In-Reply-To: <1440757911-9120-5-git-send-email-lee.jones@linaro.org>

On 28/08/15 03:31, Lee Jones wrote:
> This functionality is especially useful during the testing phase.  When
> used in conjunction with Mailbox's Test Framework we can trivially conduct
> end-to-end testing i.e. boot co-processor, send and receive messages to
> the co-processor, then shut it down again (repeat as required).

This does not strike me as a particularly well defined nor suitable
interface for controlling a remote processor's state. I know you are
just extending the existing debugfs interface here, but someone ought to
remove that piece of code and make it a proper character device or
netlink or whatever that allows someone to get proper signaling of
what's going on with the remote processor state by polling or listening
to a socket.

What's the intended use case behind debugfs for this after all? Is your
application expected to keep reading the state file in a loop until it
is happy and reads "running", how is that not racy by nature?

> 
> Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
>  drivers/remoteproc/remoteproc_debugfs.c | 29 +++++++++++++++++++++++++++++
>  1 file changed, 29 insertions(+)
> 
> diff --git a/drivers/remoteproc/remoteproc_debugfs.c b/drivers/remoteproc/remoteproc_debugfs.c
> index 9d30809..464470d 100644
> --- a/drivers/remoteproc/remoteproc_debugfs.c
> +++ b/drivers/remoteproc/remoteproc_debugfs.c
> @@ -88,8 +88,37 @@ static ssize_t rproc_state_read(struct file *filp, char __user *userbuf,
>  	return simple_read_from_buffer(userbuf, count, ppos, buf, i);
>  }
>  
> +static ssize_t rproc_state_write(struct file *filp, const char __user *userbuf,
> +				 size_t count, loff_t *ppos)
> +{
> +	struct rproc *rproc = filp->private_data;
> +	char buf[2];
> +	int ret;
> +
> +	ret = copy_from_user(buf, userbuf, 1);
> +	if (ret)
> +		return -EFAULT;
> +
> +	switch (buf[0]) {
> +	case '0':
> +		rproc_shutdown(rproc);
> +		break;
> +	case '1':
> +		ret = rproc_boot(rproc);
> +		if (ret)
> +			dev_warn(&rproc->dev, "Boot failed: %d\n", ret);
> +		break;
> +	default:
> +		dev_err(&rproc->dev, "Unrecognised option: %x\n", buf[1]);
> +		return -EINVAL;
> +	}
> +
> +	return count;
> +}
> +
>  static const struct file_operations rproc_state_ops = {
>  	.read = rproc_state_read,
> +	.write = rproc_state_write,
>  	.open = simple_open,
>  	.llseek	= generic_file_llseek,
>  };
> 


-- 
Florian

WARNING: multiple messages have this Message-ID (diff)
From: Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: ohad-Ix1uc/W3ht7QT0dZR+AlfA@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	kernel-F5mvAk5X5gdBDgjK7y7TUQ@public.gmane.org,
	Nathan_Lynch-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org,
	Ludovic Barre <ludovic.barre-qxv4g6HH51o@public.gmane.org>
Subject: Re: [PATCH v2 4/4] remoteproc: debugfs: Add ability to boot remote processor using debugfs
Date: Fri, 28 Aug 2015 10:17:28 -0700	[thread overview]
Message-ID: <55E097A8.4080305@gmail.com> (raw)
In-Reply-To: <1440757911-9120-5-git-send-email-lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>

On 28/08/15 03:31, Lee Jones wrote:
> This functionality is especially useful during the testing phase.  When
> used in conjunction with Mailbox's Test Framework we can trivially conduct
> end-to-end testing i.e. boot co-processor, send and receive messages to
> the co-processor, then shut it down again (repeat as required).

This does not strike me as a particularly well defined nor suitable
interface for controlling a remote processor's state. I know you are
just extending the existing debugfs interface here, but someone ought to
remove that piece of code and make it a proper character device or
netlink or whatever that allows someone to get proper signaling of
what's going on with the remote processor state by polling or listening
to a socket.

What's the intended use case behind debugfs for this after all? Is your
application expected to keep reading the state file in a loop until it
is happy and reads "running", how is that not racy by nature?

> 
> Signed-off-by: Ludovic Barre <ludovic.barre-qxv4g6HH51o@public.gmane.org>
> Signed-off-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
>  drivers/remoteproc/remoteproc_debugfs.c | 29 +++++++++++++++++++++++++++++
>  1 file changed, 29 insertions(+)
> 
> diff --git a/drivers/remoteproc/remoteproc_debugfs.c b/drivers/remoteproc/remoteproc_debugfs.c
> index 9d30809..464470d 100644
> --- a/drivers/remoteproc/remoteproc_debugfs.c
> +++ b/drivers/remoteproc/remoteproc_debugfs.c
> @@ -88,8 +88,37 @@ static ssize_t rproc_state_read(struct file *filp, char __user *userbuf,
>  	return simple_read_from_buffer(userbuf, count, ppos, buf, i);
>  }
>  
> +static ssize_t rproc_state_write(struct file *filp, const char __user *userbuf,
> +				 size_t count, loff_t *ppos)
> +{
> +	struct rproc *rproc = filp->private_data;
> +	char buf[2];
> +	int ret;
> +
> +	ret = copy_from_user(buf, userbuf, 1);
> +	if (ret)
> +		return -EFAULT;
> +
> +	switch (buf[0]) {
> +	case '0':
> +		rproc_shutdown(rproc);
> +		break;
> +	case '1':
> +		ret = rproc_boot(rproc);
> +		if (ret)
> +			dev_warn(&rproc->dev, "Boot failed: %d\n", ret);
> +		break;
> +	default:
> +		dev_err(&rproc->dev, "Unrecognised option: %x\n", buf[1]);
> +		return -EINVAL;
> +	}
> +
> +	return count;
> +}
> +
>  static const struct file_operations rproc_state_ops = {
>  	.read = rproc_state_read,
> +	.write = rproc_state_write,
>  	.open = simple_open,
>  	.llseek	= generic_file_llseek,
>  };
> 


-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Florian Fainelli <f.fainelli@gmail.com>
To: Lee Jones <lee.jones@linaro.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Cc: ohad@wizery.com, devicetree@vger.kernel.org, kernel@stlinux.com,
	Nathan_Lynch@mentor.com, Ludovic Barre <ludovic.barre@st.com>
Subject: Re: [PATCH v2 4/4] remoteproc: debugfs: Add ability to boot remote processor using debugfs
Date: Fri, 28 Aug 2015 10:17:28 -0700	[thread overview]
Message-ID: <55E097A8.4080305@gmail.com> (raw)
In-Reply-To: <1440757911-9120-5-git-send-email-lee.jones@linaro.org>

On 28/08/15 03:31, Lee Jones wrote:
> This functionality is especially useful during the testing phase.  When
> used in conjunction with Mailbox's Test Framework we can trivially conduct
> end-to-end testing i.e. boot co-processor, send and receive messages to
> the co-processor, then shut it down again (repeat as required).

This does not strike me as a particularly well defined nor suitable
interface for controlling a remote processor's state. I know you are
just extending the existing debugfs interface here, but someone ought to
remove that piece of code and make it a proper character device or
netlink or whatever that allows someone to get proper signaling of
what's going on with the remote processor state by polling or listening
to a socket.

What's the intended use case behind debugfs for this after all? Is your
application expected to keep reading the state file in a loop until it
is happy and reads "running", how is that not racy by nature?

> 
> Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
>  drivers/remoteproc/remoteproc_debugfs.c | 29 +++++++++++++++++++++++++++++
>  1 file changed, 29 insertions(+)
> 
> diff --git a/drivers/remoteproc/remoteproc_debugfs.c b/drivers/remoteproc/remoteproc_debugfs.c
> index 9d30809..464470d 100644
> --- a/drivers/remoteproc/remoteproc_debugfs.c
> +++ b/drivers/remoteproc/remoteproc_debugfs.c
> @@ -88,8 +88,37 @@ static ssize_t rproc_state_read(struct file *filp, char __user *userbuf,
>  	return simple_read_from_buffer(userbuf, count, ppos, buf, i);
>  }
>  
> +static ssize_t rproc_state_write(struct file *filp, const char __user *userbuf,
> +				 size_t count, loff_t *ppos)
> +{
> +	struct rproc *rproc = filp->private_data;
> +	char buf[2];
> +	int ret;
> +
> +	ret = copy_from_user(buf, userbuf, 1);
> +	if (ret)
> +		return -EFAULT;
> +
> +	switch (buf[0]) {
> +	case '0':
> +		rproc_shutdown(rproc);
> +		break;
> +	case '1':
> +		ret = rproc_boot(rproc);
> +		if (ret)
> +			dev_warn(&rproc->dev, "Boot failed: %d\n", ret);
> +		break;
> +	default:
> +		dev_err(&rproc->dev, "Unrecognised option: %x\n", buf[1]);
> +		return -EINVAL;
> +	}
> +
> +	return count;
> +}
> +
>  static const struct file_operations rproc_state_ops = {
>  	.read = rproc_state_read,
> +	.write = rproc_state_write,
>  	.open = simple_open,
>  	.llseek	= generic_file_llseek,
>  };
> 


-- 
Florian

  parent reply	other threads:[~2015-08-28 17:17 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-28 10:31 [PATCH v2 0/4] remoteproc: Add driver for STMicroelectronics platforms Lee Jones
2015-08-28 10:31 ` Lee Jones
2015-08-28 10:31 ` [PATCH v2 1/4] ARM: STiH407: Add nodes for RemoteProc Lee Jones
2015-08-28 10:31   ` Lee Jones
2015-09-01  8:28   ` [STLinux Kernel] " Peter Griffin
2015-09-01  8:28     ` Peter Griffin
2015-09-01  8:28     ` Peter Griffin
2015-09-01  9:11     ` Lee Jones
2015-09-01  9:11       ` Lee Jones
2015-09-01  9:11       ` Lee Jones
2015-09-01  9:17       ` Peter Griffin
2015-09-01  9:17         ` Peter Griffin
2015-09-01  9:17         ` Peter Griffin
2015-08-28 10:31 ` [PATCH v2 2/4] remoteproc: dt: Provide bindings for ST's Remote Processor Controller driver Lee Jones
2015-08-28 10:31   ` Lee Jones
2015-08-31 15:28   ` Rob Herring
2015-08-31 15:28     ` Rob Herring
2015-08-31 15:28     ` Rob Herring
2015-09-01 10:41     ` Lee Jones
2015-09-01 10:41       ` Lee Jones
2015-09-01 11:49       ` Rob Herring
2015-09-01 11:49         ` Rob Herring
2015-09-01 11:49         ` Rob Herring
2015-09-01  8:58   ` [STLinux Kernel] " Peter Griffin
2015-09-01  8:58     ` Peter Griffin
2015-09-01  9:14     ` Lee Jones
2015-09-01  9:14       ` Lee Jones
2015-09-01  9:14       ` Lee Jones
2015-09-01 12:54     ` Lee Jones
2015-09-01 12:54       ` Lee Jones
2015-08-28 10:31 ` [PATCH v2 3/4] remoteproc: Supply controller driver for ST's Remote Processors Lee Jones
2015-08-28 10:31   ` Lee Jones
2015-08-28 16:24   ` Nathan Lynch
2015-08-28 16:24     ` Nathan Lynch
2015-08-28 16:24     ` Nathan Lynch
2015-09-01  7:55     ` Lee Jones
2015-09-01  7:55       ` Lee Jones
2015-09-01  7:55       ` Lee Jones
2015-09-01  8:17       ` [STLinux Kernel] " Peter Griffin
2015-09-01  8:17         ` Peter Griffin
2015-09-01  9:12         ` Lee Jones
2015-09-01  9:12           ` Lee Jones
2015-09-01  9:12           ` Lee Jones
2015-08-28 10:31 ` [PATCH v2 4/4] remoteproc: debugfs: Add ability to boot remote processor using debugfs Lee Jones
2015-08-28 10:31   ` Lee Jones
2015-08-28 15:23   ` Nathan Lynch
2015-08-28 15:23     ` Nathan Lynch
2015-08-28 15:23     ` Nathan Lynch
2015-09-01  7:48     ` Lee Jones
2015-09-01  7:48       ` Lee Jones
2015-08-28 17:17   ` Florian Fainelli [this message]
2015-08-28 17:17     ` Florian Fainelli
2015-08-28 17:17     ` Florian Fainelli
2015-09-01  7:41     ` Lee Jones
2015-09-01  7:41       ` Lee Jones
2015-09-01  7:41       ` Lee Jones

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=55E097A8.4080305@gmail.com \
    --to=f.fainelli@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.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.