[RESEND v4 0/6] remoteproc: Add driver for STMicroelectronics platforms

[RESEND v4 0/6] remoteproc: Add driver for STMicroelectronics platforms

[Lee Jones]

ST's platforms often have multiple co-processors (usually ST40s or ST231s)
on-board.  This provides the Linux-side infrastructure to flash and boot
them successfully.

This set has been tested on an STiH410-B2120.

v3 => v4:
 Suggested-by: Suman Anna <s-anna-l0cyMroinI0@public.gmane.org>
 - Move to using 'reserved-memory' API
   - New 'reserved-memory' nodes
   - Remove memory locations from RemoteProc's DT node's reg properties
   - Remove C code obtaining/allocating DMA memory
 - Re-order .start() and .stop() ops
 - Add protection around Reset API in error path
 - Explicitly set .has_iommu to false

v2 => v3:
 - Generify syscon property (st,syscfg-boot => st,syscfg)
 - Rename IP in DT bindings doc (Remote Processor => Co-Processor)
 - Remove superfluous 'clock-names' property
 - Remove superfluous 'reg-names' property
 - Populate MAINTAINERS
 - Clean-up DTS formatting
 - Use strings in debugfs to control procs ('1|0' => 'start|stop')
 - Align copyright statement with MODULE() macros
 - Rename driver data structure ('st_rproc' => 'ddata')
 - Addition of a full error path in .start()

v1 => v2:
 - Remove Linux implementation specific comment from binding document
 - Force debugfs '0' to shutdown co-processor - rather than !1
 - Supply more detailed commit message
 - Propagate errors back from .stop()
 - Review GPL wording
 - Supply original author's SoBs

Lee Jones (6):
  remoteproc: dt: Provide bindings for ST's Remote Processor Controller
    driver
  remoteproc: debugfs: Add ability to boot remote processor using
    debugfs
  remoteproc: Supply controller driver for ST's Remote Processors
  MAINTAINERS: Add ST's Remote Processor Driver to ARM/STI ARCHITECTURE
  ARM: STiH407: Add nodes for RemoteProc
  ARM: STiH407: Move over to using the 'reserved-memory' API for
    obtaining DMA memory

 .../devicetree/bindings/remoteproc/st-rproc.txt    |  41 +++
 MAINTAINERS                                        |   1 +
 arch/arm/boot/dts/stih407-family.dtsi              |  70 +++++
 drivers/remoteproc/Kconfig                         |   9 +
 drivers/remoteproc/Makefile                        |   1 +
 drivers/remoteproc/remoteproc_debugfs.c            |  34 +++
 drivers/remoteproc/st_remoteproc.c                 | 297 +++++++++++++++++++++
 7 files changed, 453 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/remoteproc/st-rproc.txt
 create mode 100644 drivers/remoteproc/st_remoteproc.c

-- 
1.9.1

--
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

[RESEND v4 1/6] remoteproc: dt: Provide bindings for ST's Remote Processor Controller driver

[Lee Jones]

Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 .../devicetree/bindings/remoteproc/st-rproc.txt    | 41 ++++++++++++++++++++++
 1 file changed, 41 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/remoteproc/st-rproc.txt

diff --git a/Documentation/devicetree/bindings/remoteproc/st-rproc.txt b/Documentation/devicetree/bindings/remoteproc/st-rproc.txt
new file mode 100644
index 0000000..1031bcd
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/st-rproc.txt
@@ -0,0 +1,41 @@
+STMicroelectronics Co-Processor Bindings
+----------------------------------------
+
+This binding provides support for adjunct processors found on ST SoCs.
+
+Co-processors can be controlled from the bootloader or the primary OS. If
+the bootloader starts a co-processor, the primary OS must detect its state
+and act accordingly.
+
+Required properties:
+- compatible		Should be one of:
+				"st,st231-rproc"
+				"st,st40-rproc"
+- memory-region		Reserved memory (See: ../reserved-memory/reserved-memory.txt)
+- resets		Reset lines (See: ../reset/reset.txt)
+- reset-names		Must be "sw_reset" and "pwr_reset"
+- clocks		Clock for co-processor (See: ../clock/clock-bindings.txt)
+- clock-frequency	Clock frequency to set co-processor at if the bootloader
+			hasn't already done so
+- st,syscfg		System configuration register which holds the boot vector
+			for the co-processor
+				1st cell: Phandle to syscon block
+				2nd cell: Boot vector register offset
+
+Example:
+
+	audio_reserved: rproc@42000000 {
+		compatible = "shared-dma-pool";
+		reg = <0x42000000 0x01000000>;
+		no-map;
+	};
+
+	st231-audio {
+		compatible	= "st,st231-rproc";
+		memory-region	= <&audio_reserved>;
+		resets		= <&softreset STIH407_ST231_AUD_SOFTRESET>;
+		reset-names	= "sw_reset";
+		clocks		= <&clk_s_c0_flexgen CLK_ST231_AUD_0>;
+		clock-frequency	= <600000000>;
+		st,syscfg	= <&syscfg_core 0x228>;
+	};
-- 
1.9.1

Re: [RESEND v4 1/6] remoteproc: dt: Provide bindings for ST's Remote Processor Controller driver

[Rob Herring]

On Tue, Nov 24, 2015 at 01:14:17PM +0000, Lee Jones wrote:
> Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
>  .../devicetree/bindings/remoteproc/st-rproc.txt    | 41 ++++++++++++++++++++++

Acked-by: Rob Herring <robh@kernel.org>

>  1 file changed, 41 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/remoteproc/st-rproc.txt
> 
> diff --git a/Documentation/devicetree/bindings/remoteproc/st-rproc.txt b/Documentation/devicetree/bindings/remoteproc/st-rproc.txt
> new file mode 100644
> index 0000000..1031bcd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/remoteproc/st-rproc.txt
> @@ -0,0 +1,41 @@
> +STMicroelectronics Co-Processor Bindings
> +----------------------------------------
> +
> +This binding provides support for adjunct processors found on ST SoCs.
> +
> +Co-processors can be controlled from the bootloader or the primary OS. If
> +the bootloader starts a co-processor, the primary OS must detect its state
> +and act accordingly.
> +
> +Required properties:
> +- compatible		Should be one of:
> +				"st,st231-rproc"
> +				"st,st40-rproc"
> +- memory-region		Reserved memory (See: ../reserved-memory/reserved-memory.txt)
> +- resets		Reset lines (See: ../reset/reset.txt)
> +- reset-names		Must be "sw_reset" and "pwr_reset"
> +- clocks		Clock for co-processor (See: ../clock/clock-bindings.txt)
> +- clock-frequency	Clock frequency to set co-processor at if the bootloader
> +			hasn't already done so
> +- st,syscfg		System configuration register which holds the boot vector
> +			for the co-processor
> +				1st cell: Phandle to syscon block
> +				2nd cell: Boot vector register offset
> +
> +Example:
> +
> +	audio_reserved: rproc@42000000 {
> +		compatible = "shared-dma-pool";
> +		reg = <0x42000000 0x01000000>;
> +		no-map;
> +	};
> +
> +	st231-audio {
> +		compatible	= "st,st231-rproc";
> +		memory-region	= <&audio_reserved>;
> +		resets		= <&softreset STIH407_ST231_AUD_SOFTRESET>;
> +		reset-names	= "sw_reset";
> +		clocks		= <&clk_s_c0_flexgen CLK_ST231_AUD_0>;
> +		clock-frequency	= <600000000>;
> +		st,syscfg	= <&syscfg_core 0x228>;
> +	};
> -- 
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND v4 1/6] remoteproc: dt: Provide bindings for ST's Remote Processor Controller driver

[Bjorn Andersson]

On Tue, Nov 24, 2015 at 5:14 AM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> Signed-off-by: Ludovic Barre <ludovic.barre-qxv4g6HH51o@public.gmane.org>
> Signed-off-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---

Acked-by: Bjorn Andersson <bjorn.andersson-/MT0OVThwyLZJqsBc5GL+g@public.gmane.org>

Regards,
Bjorn

>  .../devicetree/bindings/remoteproc/st-rproc.txt    | 41 ++++++++++++++++++++++
>  1 file changed, 41 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/remoteproc/st-rproc.txt
>
> diff --git a/Documentation/devicetree/bindings/remoteproc/st-rproc.txt b/Documentation/devicetree/bindings/remoteproc/st-rproc.txt
> new file mode 100644
> index 0000000..1031bcd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/remoteproc/st-rproc.txt
> @@ -0,0 +1,41 @@
> +STMicroelectronics Co-Processor Bindings
> +----------------------------------------
> +
> +This binding provides support for adjunct processors found on ST SoCs.
> +
> +Co-processors can be controlled from the bootloader or the primary OS. If
> +the bootloader starts a co-processor, the primary OS must detect its state
> +and act accordingly.
> +
> +Required properties:
> +- compatible           Should be one of:
> +                               "st,st231-rproc"
> +                               "st,st40-rproc"
> +- memory-region                Reserved memory (See: ../reserved-memory/reserved-memory.txt)
> +- resets               Reset lines (See: ../reset/reset.txt)
> +- reset-names          Must be "sw_reset" and "pwr_reset"
> +- clocks               Clock for co-processor (See: ../clock/clock-bindings.txt)
> +- clock-frequency      Clock frequency to set co-processor at if the bootloader
> +                       hasn't already done so
> +- st,syscfg            System configuration register which holds the boot vector
> +                       for the co-processor
> +                               1st cell: Phandle to syscon block
> +                               2nd cell: Boot vector register offset
> +
> +Example:
> +
> +       audio_reserved: rproc@42000000 {
> +               compatible = "shared-dma-pool";
> +               reg = <0x42000000 0x01000000>;
> +               no-map;
> +       };
> +
> +       st231-audio {
> +               compatible      = "st,st231-rproc";
> +               memory-region   = <&audio_reserved>;
> +               resets          = <&softreset STIH407_ST231_AUD_SOFTRESET>;
> +               reset-names     = "sw_reset";
> +               clocks          = <&clk_s_c0_flexgen CLK_ST231_AUD_0>;
> +               clock-frequency = <600000000>;
> +               st,syscfg       = <&syscfg_core 0x228>;
> +       };
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
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

[RESEND v4 2/6] remoteproc: debugfs: Add ability to boot remote processor using debugfs

[Lee Jones]

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).

Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 drivers/remoteproc/remoteproc_debugfs.c | 34 +++++++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/drivers/remoteproc/remoteproc_debugfs.c b/drivers/remoteproc/remoteproc_debugfs.c
index 9d30809..8113c18 100644
--- a/drivers/remoteproc/remoteproc_debugfs.c
+++ b/drivers/remoteproc/remoteproc_debugfs.c
@@ -88,8 +88,42 @@ 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[10];
+	int ret;
+
+	if (count > sizeof(buf))
+		return count;
+
+	ret = copy_from_user(buf, userbuf, count);
+	if (ret)
+		return -EFAULT;
+
+	if (buf[count - 1] == '\n')
+		buf[count - 1] = '\0';
+
+	if (!strncmp(buf, "start", count)) {
+		ret = rproc_boot(rproc);
+		if (ret) {
+			dev_err(&rproc->dev, "Boot failed: %d\n", ret);
+			return ret;
+		}
+	} else if (!strncmp(buf, "stop", count)) {
+		rproc_shutdown(rproc);
+	} else {
+		dev_err(&rproc->dev, "Unrecognised option: %s\n", buf);
+		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,
 };
-- 
1.9.1

Re: [RESEND v4 2/6] remoteproc: debugfs: Add ability to boot remote processor using debugfs

[Bjorn Andersson]

On Tue, Nov 24, 2015 at 5:14 AM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 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).
>

I want this too!

> 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 | 34 +++++++++++++++++++++++++++++++++
>  1 file changed, 34 insertions(+)
>
> diff --git a/drivers/remoteproc/remoteproc_debugfs.c b/drivers/remoteproc/remoteproc_debugfs.c
> index 9d30809..8113c18 100644
> --- a/drivers/remoteproc/remoteproc_debugfs.c
> +++ b/drivers/remoteproc/remoteproc_debugfs.c
> @@ -88,8 +88,42 @@ 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[10];
> +       int ret;
> +
> +       if (count > sizeof(buf))
> +               return count;
> +
> +       ret = copy_from_user(buf, userbuf, count);
> +       if (ret)
> +               return -EFAULT;
> +
> +       if (buf[count - 1] == '\n')
> +               buf[count - 1] = '\0';

I believe you can get here with count = 0.

> +
> +       if (!strncmp(buf, "start", count)) {
> +               ret = rproc_boot(rproc);
> +               if (ret) {
> +                       dev_err(&rproc->dev, "Boot failed: %d\n", ret);
> +                       return ret;
> +               }
> +       } else if (!strncmp(buf, "stop", count)) {
> +               rproc_shutdown(rproc);
> +       } else {
> +               dev_err(&rproc->dev, "Unrecognised option: %s\n", buf);

Unrecognized

> +               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,
>  };

Part of these nits

Acked-by: Bjorn Andersson <bjorn.andersson-/MT0OVThwyLZJqsBc5GL+g@public.gmane.org>

Regards,
Bjorn
--
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

Re: [RESEND v4 2/6] remoteproc: debugfs: Add ability to boot remote processor using debugfs

[Lee Jones]

On Fri, 27 Nov 2015, Bjorn Andersson wrote:

> On Tue, Nov 24, 2015 at 5:14 AM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 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).
> >
> 
> I want this too!
> 
> > 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 | 34 +++++++++++++++++++++++++++++++++
> >  1 file changed, 34 insertions(+)
> >
> > diff --git a/drivers/remoteproc/remoteproc_debugfs.c b/drivers/remoteproc/remoteproc_debugfs.c
> > index 9d30809..8113c18 100644
> > --- a/drivers/remoteproc/remoteproc_debugfs.c
> > +++ b/drivers/remoteproc/remoteproc_debugfs.c
> > @@ -88,8 +88,42 @@ 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[10];
> > +       int ret;
> > +
> > +       if (count > sizeof(buf))
> > +               return count;
> > +
> > +       ret = copy_from_user(buf, userbuf, count);
> > +       if (ret)
> > +               return -EFAULT;
> > +
> > +       if (buf[count - 1] == '\n')
> > +               buf[count - 1] = '\0';
> 
> I believe you can get here with count = 0.

I'm pretty sure you can't.

If you are sure that you can, if you can provide me with a way of
testing, I'd be happy to put in provisions.

> > +
> > +       if (!strncmp(buf, "start", count)) {
> > +               ret = rproc_boot(rproc);
> > +               if (ret) {
> > +                       dev_err(&rproc->dev, "Boot failed: %d\n", ret);
> > +                       return ret;
> > +               }
> > +       } else if (!strncmp(buf, "stop", count)) {
> > +               rproc_shutdown(rproc);
> > +       } else {
> > +               dev_err(&rproc->dev, "Unrecognised option: %s\n", buf);
> 
> Unrecognized

What I have is correct.

> > +               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,
> >  };
> 
> Part of these nits
> 
> Acked-by: Bjorn Andersson <bjorn.andersson-/MT0OVThwyLZJqsBc5GL+g@public.gmane.org>

Thanks.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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

Re: [RESEND v4 2/6] remoteproc: debugfs: Add ability to boot remote processor using debugfs

[Arnd Bergmann]

On Thursday 03 December 2015 12:26:34 Lee Jones wrote:
> > >
> > > +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[10];
> > > +       int ret;
> > > +
> > > +       if (count > sizeof(buf))
> > > +               return count;
> > > +       ret = copy_from_user(buf, userbuf, count);
> > > +       if (ret)
> > > +               return -EFAULT;
> > > +
> > > +       if (buf[count - 1] == '\n')
> > > +               buf[count - 1] = '\0';
> > 
> > I believe you can get here with count = 0.
> 
> I'm pretty sure you can't.
> 
> If you are sure that you can, if you can provide me with a way of
> testing, I'd be happy to put in provisions.
> 

I think that a zero-length write() from user space ends up in the write
file operation.

Also, we get a gcc warning about the out-of-bounds access for code like
this, and checking that count is larger than zero avoids the warning.

	Arnd

Re: [RESEND v4 2/6] remoteproc: debugfs: Add ability to boot remote processor using debugfs

[Lee Jones]

On Thu, 03 Dec 2015, Arnd Bergmann wrote:

> On Thursday 03 December 2015 12:26:34 Lee Jones wrote:
> > > >
> > > > +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[10];
> > > > +       int ret;
> > > > +
> > > > +       if (count > sizeof(buf))
> > > > +               return count;
> > > > +       ret = copy_from_user(buf, userbuf, count);
> > > > +       if (ret)
> > > > +               return -EFAULT;
> > > > +
> > > > +       if (buf[count - 1] == '\n')
> > > > +               buf[count - 1] = '\0';
> > > 
> > > I believe you can get here with count = 0.
> > 
> > I'm pretty sure you can't.
> > 
> > If you are sure that you can, if you can provide me with a way of
> > testing, I'd be happy to put in provisions.
> > 
> 
> I think that a zero-length write() from user space ends up in the write
> file operation.

I tested this and didn't see it enter write().  My conclusion was that
if the file doesn't change, then nothing is triggered.

> Also, we get a gcc warning about the out-of-bounds access for code like
> this, and checking that count is larger than zero avoids the warning.

I did however see this warning and wondered what it was talking
about.  Thanks for clarifying.  Will fix.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [RESEND v4 2/6] remoteproc: debugfs: Add ability to boot remote processor using debugfs

[Arnd Bergmann]

On Thursday 03 December 2015 13:03:41 Lee Jones wrote:
> On Thu, 03 Dec 2015, Arnd Bergmann wrote:
> 
> > On Thursday 03 December 2015 12:26:34 Lee Jones wrote:
> > > > >
> > > > > +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[10];
> > > > > +       int ret;
> > > > > +
> > > > > +       if (count > sizeof(buf))
> > > > > +               return count;
> > > > > +       ret = copy_from_user(buf, userbuf, count);
> > > > > +       if (ret)
> > > > > +               return -EFAULT;
> > > > > +
> > > > > +       if (buf[count - 1] == '\n')
> > > > > +               buf[count - 1] = '\0';
> > > > 
> > > > I believe you can get here with count = 0.
> > > 
> > > I'm pretty sure you can't.
> > > 
> > > If you are sure that you can, if you can provide me with a way of
> > > testing, I'd be happy to put in provisions.
> > > 
> > 
> > I think that a zero-length write() from user space ends up in the write
> > file operation.
> 
> I tested this and didn't see it enter write().  My conclusion was that
> if the file doesn't change, then nothing is triggered.
> 

Ah, interesting. I haven't tried myself, and just tried to read the
code. Maybe glibc already catches zero-length writes before it gets
into the kernel, or I just missed the part of the syscall that checks
for this.

	arnd

Re: [RESEND v4 2/6] remoteproc: debugfs: Add ability to boot remote processor using debugfs

[Lee Jones]

On Thu, 03 Dec 2015, Arnd Bergmann wrote:

> On Thursday 03 December 2015 13:03:41 Lee Jones wrote:
> > On Thu, 03 Dec 2015, Arnd Bergmann wrote:
> > 
> > > On Thursday 03 December 2015 12:26:34 Lee Jones wrote:
> > > > > >
> > > > > > +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[10];
> > > > > > +       int ret;
> > > > > > +
> > > > > > +       if (count > sizeof(buf))
> > > > > > +               return count;
> > > > > > +       ret = copy_from_user(buf, userbuf, count);
> > > > > > +       if (ret)
> > > > > > +               return -EFAULT;
> > > > > > +
> > > > > > +       if (buf[count - 1] == '\n')
> > > > > > +               buf[count - 1] = '\0';
> > > > > 
> > > > > I believe you can get here with count = 0.
> > > > 
> > > > I'm pretty sure you can't.
> > > > 
> > > > If you are sure that you can, if you can provide me with a way of
> > > > testing, I'd be happy to put in provisions.
> > > > 
> > > 
> > > I think that a zero-length write() from user space ends up in the write
> > > file operation.
> > 
> > I tested this and didn't see it enter write().  My conclusion was that
> > if the file doesn't change, then nothing is triggered.
> > 
> 
> Ah, interesting. I haven't tried myself, and just tried to read the
> code. Maybe glibc already catches zero-length writes before it gets
> into the kernel, or I just missed the part of the syscall that checks
> for this.

Glibc is responsible indeed:
  
  http://osxr.org/glibc/source/io/write.c

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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

Re: [RESEND v4 2/6] remoteproc: debugfs: Add ability to boot remote processor using debugfs

[Arnd Bergmann]

On Thursday 03 December 2015 17:28:30 Lee Jones wrote:
> > 
> > Ah, interesting. I haven't tried myself, and just tried to read the
> > code. Maybe glibc already catches zero-length writes before it gets
> > into the kernel, or I just missed the part of the syscall that checks
> > for this.
> 
> Glibc is responsible indeed:
>   
>   http://osxr.org/glibc/source/io/write.c

Ok, so an attacker can force the stack overflow by calling
syscall(__NR_write, fd, p, 0) if that has any potential value,
but normal users won't hit this case.

	Arnd

Re: [RESEND v4 2/6] remoteproc: debugfs: Add ability to boot remote processor using debugfs

[Bjorn Andersson]

On Thu, Dec 3, 2015 at 1:12 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 03 December 2015 17:28:30 Lee Jones wrote:
>> >
>> > Ah, interesting. I haven't tried myself, and just tried to read the
>> > code. Maybe glibc already catches zero-length writes before it gets
>> > into the kernel, or I just missed the part of the syscall that checks
>> > for this.
>>
>> Glibc is responsible indeed:
>>
>>   http://osxr.org/glibc/source/io/write.c
>
> Ok, so an attacker can force the stack overflow by calling
> syscall(__NR_write, fd, p, 0) if that has any potential value,
> but normal users won't hit this case.
>

It seems glibc might be the only libc implementation with this protection.

Regards,
Bjorn

Re: [RESEND v4 2/6] remoteproc: debugfs: Add ability to boot remote processor using debugfs

[Lee Jones]

On Thu, 03 Dec 2015, Arnd Bergmann wrote:

> On Thursday 03 December 2015 17:28:30 Lee Jones wrote:
> > > 
> > > Ah, interesting. I haven't tried myself, and just tried to read the
> > > code. Maybe glibc already catches zero-length writes before it gets
> > > into the kernel, or I just missed the part of the syscall that checks
> > > for this.
> > 
> > Glibc is responsible indeed:
> >   
> >   http://osxr.org/glibc/source/io/write.c
> 
> Ok, so an attacker can force the stack overflow by calling
> syscall(__NR_write, fd, p, 0) if that has any potential value,
> but normal users won't hit this case.

Right.  I have fixed the issue (and another one I found) anyway, if
only to rid the GCC warning.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [RESEND v4 2/6] remoteproc: debugfs: Add ability to boot remote processor using debugfs

[Bjorn Andersson]

On Fri, Dec 4, 2015 at 12:24 AM, Lee Jones <lee.jones@linaro.org> wrote:
> On Thu, 03 Dec 2015, Arnd Bergmann wrote:
>
>> On Thursday 03 December 2015 17:28:30 Lee Jones wrote:
>> > >
>> > > Ah, interesting. I haven't tried myself, and just tried to read the
>> > > code. Maybe glibc already catches zero-length writes before it gets
>> > > into the kernel, or I just missed the part of the syscall that checks
>> > > for this.
>> >
>> > Glibc is responsible indeed:
>> >
>> >   http://osxr.org/glibc/source/io/write.c
>>
>> Ok, so an attacker can force the stack overflow by calling
>> syscall(__NR_write, fd, p, 0) if that has any potential value,
>> but normal users won't hit this case.
>
> Right.  I have fixed the issue (and another one I found) anyway, if
> only to rid the GCC warning.
>

Sorry, but I'm unable to find a new version of this patch, did I miss
it or could you resend it?


Also, as I looked at this again, we should probably return an error if
count >= sizeof(buf) rather than just acknowledging the input (same in
the other debugfs write function in this file).

Regards,
Bjorn

Re: [RESEND v4 2/6] remoteproc: debugfs: Add ability to boot remote processor using debugfs

[Lee Jones]

On Mon, 28 Dec 2015, Bjorn Andersson wrote:

> On Fri, Dec 4, 2015 at 12:24 AM, Lee Jones <lee.jones@linaro.org> wrote:
> > On Thu, 03 Dec 2015, Arnd Bergmann wrote:
> >
> >> On Thursday 03 December 2015 17:28:30 Lee Jones wrote:
> >> > >
> >> > > Ah, interesting. I haven't tried myself, and just tried to read the
> >> > > code. Maybe glibc already catches zero-length writes before it gets
> >> > > into the kernel, or I just missed the part of the syscall that checks
> >> > > for this.
> >> >
> >> > Glibc is responsible indeed:
> >> >
> >> >   http://osxr.org/glibc/source/io/write.c
> >>
> >> Ok, so an attacker can force the stack overflow by calling
> >> syscall(__NR_write, fd, p, 0) if that has any potential value,
> >> but normal users won't hit this case.
> >
> > Right.  I have fixed the issue (and another one I found) anyway, if
> > only to rid the GCC warning.
> >
> 
> Sorry, but I'm unable to find a new version of this patch, did I miss
> it or could you resend it?

I didn't send it out.  Just looking at this again, post-vacation.

> Also, as I looked at this again, we should probably return an error if
> count >= sizeof(buf) rather than just acknowledging the input (same in
> the other debugfs write function in this file).

Sure.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[RESEND v4 3/6] remoteproc: Supply controller driver for ST's Remote Processors

[Lee Jones]

Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 drivers/remoteproc/Kconfig         |   9 ++
 drivers/remoteproc/Makefile        |   1 +
 drivers/remoteproc/st_remoteproc.c | 297 +++++++++++++++++++++++++++++++++++++
 3 files changed, 307 insertions(+)
 create mode 100644 drivers/remoteproc/st_remoteproc.c

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 28c711f..72e97d7 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -77,4 +77,13 @@ config DA8XX_REMOTEPROC
 	  It's safe to say n here if you're not interested in multimedia
 	  offloading.
 
+config ST_REMOTEPROC
+	tristate "ST remoteproc support"
+	depends on ARCH_STI
+	select REMOTEPROC
+	help
+	  Say y here to support ST's adjunct processors via the remote
+	  processor framework.
+	  This can be either built-in or a loadable module.
+
 endmenu
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 81b04d1..279cb2e 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_OMAP_REMOTEPROC)		+= omap_remoteproc.o
 obj-$(CONFIG_STE_MODEM_RPROC)	 	+= ste_modem_rproc.o
 obj-$(CONFIG_WKUP_M3_RPROC)		+= wkup_m3_rproc.o
 obj-$(CONFIG_DA8XX_REMOTEPROC)		+= da8xx_remoteproc.o
+obj-$(CONFIG_ST_REMOTEPROC)		+= st_remoteproc.o
diff --git a/drivers/remoteproc/st_remoteproc.c b/drivers/remoteproc/st_remoteproc.c
new file mode 100644
index 0000000..6bb04d4
--- /dev/null
+++ b/drivers/remoteproc/st_remoteproc.c
@@ -0,0 +1,297 @@
+/*
+ * ST's Remote Processor Control Driver
+ *
+ * Copyright (C) 2015 STMicroelectronics - All Rights Reserved
+ *
+ * Author: Ludovic Barre <ludovic.barre@st.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/clk.h>
+#include <linux/dma-mapping.h>
+#include <linux/err.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/of_reserved_mem.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/remoteproc.h>
+#include <linux/reset.h>
+
+struct st_rproc_config {
+	bool			sw_reset;
+	bool			pwr_reset;
+	unsigned long		bootaddr_mask;
+};
+
+struct st_rproc {
+	struct st_rproc_config	*config;
+	struct reset_control	*sw_reset;
+	struct reset_control	*pwr_reset;
+	struct clk		*clk;
+	u32			clk_rate;
+	struct regmap		*boot_base;
+	u32			boot_offset;
+};
+
+static int st_rproc_start(struct rproc *rproc)
+{
+	struct st_rproc *ddata = rproc->priv;
+	int err;
+
+	regmap_update_bits(ddata->boot_base, ddata->boot_offset,
+			   ddata->config->bootaddr_mask, rproc->bootaddr);
+
+	err = clk_enable(ddata->clk);
+	if (err) {
+		dev_err(&rproc->dev, "Failed to enable clock\n");
+		return err;
+	}
+
+	if (ddata->config->sw_reset) {
+		err = reset_control_deassert(ddata->sw_reset);
+		if (err) {
+			dev_err(&rproc->dev, "Failed to deassert S/W Reset\n");
+			goto sw_reset_fail;
+		}
+	}
+
+	if (ddata->config->pwr_reset) {
+		err = reset_control_deassert(ddata->pwr_reset);
+		if (err) {
+			dev_err(&rproc->dev, "Failed to deassert Power Reset\n");
+			goto pwr_reset_fail;
+		}
+	}
+
+	dev_info(&rproc->dev, "Started from 0x%x\n", rproc->bootaddr);
+
+	return 0;
+
+
+pwr_reset_fail:
+	if (ddata->config->pwr_reset)
+		reset_control_assert(ddata->sw_reset);
+sw_reset_fail:
+	clk_disable(ddata->clk);
+
+	return err;
+}
+
+static int st_rproc_stop(struct rproc *rproc)
+{
+	struct st_rproc *ddata = rproc->priv;
+	int sw_err = 0, pwr_err = 0;
+
+	if (ddata->config->sw_reset) {
+		sw_err = reset_control_assert(ddata->sw_reset);
+		if (sw_err)
+			dev_err(&rproc->dev, "Failed to assert S/W Reset\n");
+	}
+
+	if (ddata->config->pwr_reset) {
+		pwr_err = reset_control_assert(ddata->pwr_reset);
+		if (pwr_err)
+			dev_err(&rproc->dev, "Failed to assert Power Reset\n");
+	}
+
+	clk_disable(ddata->clk);
+
+	return sw_err ?: pwr_err;
+}
+
+static struct rproc_ops st_rproc_ops = {
+	.start		= st_rproc_start,
+	.stop		= st_rproc_stop,
+};
+
+/*
+ * Fetch state of the processor: 0 is off, 1 is on.
+ */
+static int st_rproc_state(struct platform_device *pdev)
+{
+	struct rproc *rproc = platform_get_drvdata(pdev);
+	struct st_rproc *ddata = rproc->priv;
+	int reset_sw = 0, reset_pwr = 0;
+
+	if (ddata->config->sw_reset)
+		reset_sw = reset_control_status(ddata->sw_reset);
+
+	if (ddata->config->pwr_reset)
+		reset_pwr = reset_control_status(ddata->pwr_reset);
+
+	if (reset_sw < 0 || reset_pwr < 0)
+		return -EINVAL;
+
+	return !reset_sw && !reset_pwr;
+}
+
+static const struct st_rproc_config st40_rproc_cfg = {
+	.sw_reset = true,
+	.pwr_reset = true,
+	.bootaddr_mask = GENMASK(28, 1),
+};
+
+static const struct st_rproc_config st231_rproc_cfg = {
+	.sw_reset = true,
+	.pwr_reset = false,
+	.bootaddr_mask = GENMASK(31, 6),
+};
+
+static const struct of_device_id st_rproc_match[] = {
+	{ .compatible = "st,st40-rproc", .data = &st40_rproc_cfg },
+	{ .compatible = "st,st231-rproc", .data = &st231_rproc_cfg },
+	{},
+};
+MODULE_DEVICE_TABLE(of, st_rproc_match);
+
+static int st_rproc_parse_dt(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct rproc *rproc = platform_get_drvdata(pdev);
+	struct st_rproc *ddata = rproc->priv;
+	struct device_node *np = dev->of_node;
+	int err;
+
+	if (ddata->config->sw_reset) {
+		ddata->sw_reset = devm_reset_control_get(dev, "sw_reset");
+		if (IS_ERR(ddata->sw_reset)) {
+			dev_err(dev, "Failed to get S/W Reset\n");
+			return PTR_ERR(ddata->sw_reset);
+		}
+	}
+
+	if (ddata->config->pwr_reset) {
+		ddata->pwr_reset = devm_reset_control_get(dev, "pwr_reset");
+		if (IS_ERR(ddata->pwr_reset)) {
+			dev_err(dev, "Failed to get Power Reset\n");
+			return PTR_ERR(ddata->pwr_reset);
+		}
+	}
+
+	ddata->clk = devm_clk_get(dev, NULL);
+	if (IS_ERR(ddata->clk)) {
+		dev_err(dev, "Failed to get clock\n");
+		return PTR_ERR(ddata->clk);
+	}
+
+	err = of_property_read_u32(np, "clock-frequency", &ddata->clk_rate);
+	if (err) {
+		dev_err(dev, "failed to get clock frequency\n");
+		return err;
+	}
+
+	ddata->boot_base = syscon_regmap_lookup_by_phandle(np, "st,syscfg");
+	if (!ddata->boot_base) {
+		dev_err(dev, "Boot base not found\n");
+		return -EINVAL;
+	}
+
+	err = of_property_read_u32_index(np, "st,syscfg", 1,
+					 &ddata->boot_offset);
+	if (err) {
+		dev_err(dev, "Boot offset not found\n");
+		return -EINVAL;
+	}
+
+	err = of_reserved_mem_device_init(dev);
+	if (err) {
+		dev_err(dev, "Failed to obtain shared memory\n");
+		return err;
+	}
+
+	err = clk_prepare(ddata->clk);
+	if (err)
+		dev_err(dev, "failed to get clock\n");
+
+	return err;
+}
+
+static int st_rproc_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	const struct of_device_id *match;
+	struct st_rproc *ddata;
+	struct device_node *np = dev->of_node;
+	struct rproc *rproc;
+	int enabled;
+	int ret;
+
+	match = of_match_device(st_rproc_match, dev);
+	if (!match || !match->data) {
+		dev_err(dev, "No device match found\n");
+		return -ENODEV;
+	}
+
+	rproc = rproc_alloc(dev, np->name, &st_rproc_ops, NULL, sizeof(*ddata));
+	if (!rproc)
+		return -ENOMEM;
+
+	rproc->has_iommu = false;
+	ddata = rproc->priv;
+	ddata->config = (struct st_rproc_config *)match->data;
+
+	platform_set_drvdata(pdev, rproc);
+
+	ret = st_rproc_parse_dt(pdev);
+	if (ret)
+		goto free_rproc;
+
+	enabled = st_rproc_state(pdev);
+	if (enabled < 0)
+		goto free_rproc;
+
+	if (enabled) {
+		atomic_inc(&rproc->power);
+		rproc->state = RPROC_RUNNING;
+	} else {
+		clk_set_rate(ddata->clk, ddata->clk_rate);
+	}
+
+	ret = rproc_add(rproc);
+	if (ret)
+		goto free_rproc;
+
+	return 0;
+
+free_rproc:
+	rproc_put(rproc);
+	return ret;
+}
+
+static int st_rproc_remove(struct platform_device *pdev)
+{
+	struct rproc *rproc = platform_get_drvdata(pdev);
+	struct st_rproc *ddata = rproc->priv;
+
+	rproc_del(rproc);
+
+	clk_disable_unprepare(ddata->clk);
+
+	of_reserved_mem_device_release(&pdev->dev);
+
+	rproc_put(rproc);
+
+	return 0;
+}
+
+static struct platform_driver st_rproc_driver = {
+	.probe = st_rproc_probe,
+	.remove = st_rproc_remove,
+	.driver = {
+		.name = "st-rproc",
+		.of_match_table = of_match_ptr(st_rproc_match),
+	},
+};
+module_platform_driver(st_rproc_driver);
+
+MODULE_DESCRIPTION("ST Remote Processor Control Driver");
+MODULE_AUTHOR("Ludovic Barre <ludovic.barre@st.com>");
+MODULE_LICENSE("GPL v2");
-- 
1.9.1

Re: [RESEND v4 3/6] remoteproc: Supply controller driver for ST's Remote Processors

[Bjorn Andersson]

On Tue, Nov 24, 2015 at 5:14 AM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> Signed-off-by: Ludovic Barre <ludovic.barre-qxv4g6HH51o@public.gmane.org>
> Signed-off-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---

Acked-by: Bjorn Andersson <bjorn.andersson-/MT0OVThwyLZJqsBc5GL+g@public.gmane.org>

Regards,
Bjorn

>  drivers/remoteproc/Kconfig         |   9 ++
>  drivers/remoteproc/Makefile        |   1 +
>  drivers/remoteproc/st_remoteproc.c | 297 +++++++++++++++++++++++++++++++++++++
>  3 files changed, 307 insertions(+)
>  create mode 100644 drivers/remoteproc/st_remoteproc.c
>
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index 28c711f..72e97d7 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -77,4 +77,13 @@ config DA8XX_REMOTEPROC
>           It's safe to say n here if you're not interested in multimedia
>           offloading.
>
> +config ST_REMOTEPROC
> +       tristate "ST remoteproc support"
> +       depends on ARCH_STI
> +       select REMOTEPROC
> +       help
> +         Say y here to support ST's adjunct processors via the remote
> +         processor framework.
> +         This can be either built-in or a loadable module.
> +
>  endmenu
> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> index 81b04d1..279cb2e 100644
> --- a/drivers/remoteproc/Makefile
> +++ b/drivers/remoteproc/Makefile
> @@ -11,3 +11,4 @@ obj-$(CONFIG_OMAP_REMOTEPROC)         += omap_remoteproc.o
>  obj-$(CONFIG_STE_MODEM_RPROC)          += ste_modem_rproc.o
>  obj-$(CONFIG_WKUP_M3_RPROC)            += wkup_m3_rproc.o
>  obj-$(CONFIG_DA8XX_REMOTEPROC)         += da8xx_remoteproc.o
> +obj-$(CONFIG_ST_REMOTEPROC)            += st_remoteproc.o
> diff --git a/drivers/remoteproc/st_remoteproc.c b/drivers/remoteproc/st_remoteproc.c
> new file mode 100644
> index 0000000..6bb04d4
> --- /dev/null
> +++ b/drivers/remoteproc/st_remoteproc.c
> @@ -0,0 +1,297 @@
> +/*
> + * ST's Remote Processor Control Driver
> + *
> + * Copyright (C) 2015 STMicroelectronics - All Rights Reserved
> + *
> + * Author: Ludovic Barre <ludovic.barre-qxv4g6HH51o@public.gmane.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/dma-mapping.h>
> +#include <linux/err.h>
> +#include <linux/interrupt.h>
> +#include <linux/kernel.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/of_reserved_mem.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/remoteproc.h>
> +#include <linux/reset.h>
> +
> +struct st_rproc_config {
> +       bool                    sw_reset;
> +       bool                    pwr_reset;
> +       unsigned long           bootaddr_mask;
> +};
> +
> +struct st_rproc {
> +       struct st_rproc_config  *config;
> +       struct reset_control    *sw_reset;
> +       struct reset_control    *pwr_reset;
> +       struct clk              *clk;
> +       u32                     clk_rate;
> +       struct regmap           *boot_base;
> +       u32                     boot_offset;
> +};
> +
> +static int st_rproc_start(struct rproc *rproc)
> +{
> +       struct st_rproc *ddata = rproc->priv;
> +       int err;
> +
> +       regmap_update_bits(ddata->boot_base, ddata->boot_offset,
> +                          ddata->config->bootaddr_mask, rproc->bootaddr);
> +
> +       err = clk_enable(ddata->clk);
> +       if (err) {
> +               dev_err(&rproc->dev, "Failed to enable clock\n");
> +               return err;
> +       }
> +
> +       if (ddata->config->sw_reset) {
> +               err = reset_control_deassert(ddata->sw_reset);
> +               if (err) {
> +                       dev_err(&rproc->dev, "Failed to deassert S/W Reset\n");
> +                       goto sw_reset_fail;
> +               }
> +       }
> +
> +       if (ddata->config->pwr_reset) {
> +               err = reset_control_deassert(ddata->pwr_reset);
> +               if (err) {
> +                       dev_err(&rproc->dev, "Failed to deassert Power Reset\n");
> +                       goto pwr_reset_fail;
> +               }
> +       }
> +
> +       dev_info(&rproc->dev, "Started from 0x%x\n", rproc->bootaddr);
> +
> +       return 0;
> +
> +
> +pwr_reset_fail:
> +       if (ddata->config->pwr_reset)
> +               reset_control_assert(ddata->sw_reset);
> +sw_reset_fail:
> +       clk_disable(ddata->clk);
> +
> +       return err;
> +}
> +
> +static int st_rproc_stop(struct rproc *rproc)
> +{
> +       struct st_rproc *ddata = rproc->priv;
> +       int sw_err = 0, pwr_err = 0;
> +
> +       if (ddata->config->sw_reset) {
> +               sw_err = reset_control_assert(ddata->sw_reset);
> +               if (sw_err)
> +                       dev_err(&rproc->dev, "Failed to assert S/W Reset\n");
> +       }
> +
> +       if (ddata->config->pwr_reset) {
> +               pwr_err = reset_control_assert(ddata->pwr_reset);
> +               if (pwr_err)
> +                       dev_err(&rproc->dev, "Failed to assert Power Reset\n");
> +       }
> +
> +       clk_disable(ddata->clk);
> +
> +       return sw_err ?: pwr_err;
> +}
> +
> +static struct rproc_ops st_rproc_ops = {
> +       .start          = st_rproc_start,
> +       .stop           = st_rproc_stop,
> +};
> +
> +/*
> + * Fetch state of the processor: 0 is off, 1 is on.
> + */
> +static int st_rproc_state(struct platform_device *pdev)
> +{
> +       struct rproc *rproc = platform_get_drvdata(pdev);
> +       struct st_rproc *ddata = rproc->priv;
> +       int reset_sw = 0, reset_pwr = 0;
> +
> +       if (ddata->config->sw_reset)
> +               reset_sw = reset_control_status(ddata->sw_reset);
> +
> +       if (ddata->config->pwr_reset)
> +               reset_pwr = reset_control_status(ddata->pwr_reset);
> +
> +       if (reset_sw < 0 || reset_pwr < 0)
> +               return -EINVAL;
> +
> +       return !reset_sw && !reset_pwr;
> +}
> +
> +static const struct st_rproc_config st40_rproc_cfg = {
> +       .sw_reset = true,
> +       .pwr_reset = true,
> +       .bootaddr_mask = GENMASK(28, 1),
> +};
> +
> +static const struct st_rproc_config st231_rproc_cfg = {
> +       .sw_reset = true,
> +       .pwr_reset = false,
> +       .bootaddr_mask = GENMASK(31, 6),
> +};
> +
> +static const struct of_device_id st_rproc_match[] = {
> +       { .compatible = "st,st40-rproc", .data = &st40_rproc_cfg },
> +       { .compatible = "st,st231-rproc", .data = &st231_rproc_cfg },
> +       {},
> +};
> +MODULE_DEVICE_TABLE(of, st_rproc_match);
> +
> +static int st_rproc_parse_dt(struct platform_device *pdev)
> +{
> +       struct device *dev = &pdev->dev;
> +       struct rproc *rproc = platform_get_drvdata(pdev);
> +       struct st_rproc *ddata = rproc->priv;
> +       struct device_node *np = dev->of_node;
> +       int err;
> +
> +       if (ddata->config->sw_reset) {
> +               ddata->sw_reset = devm_reset_control_get(dev, "sw_reset");
> +               if (IS_ERR(ddata->sw_reset)) {
> +                       dev_err(dev, "Failed to get S/W Reset\n");
> +                       return PTR_ERR(ddata->sw_reset);
> +               }
> +       }
> +
> +       if (ddata->config->pwr_reset) {
> +               ddata->pwr_reset = devm_reset_control_get(dev, "pwr_reset");
> +               if (IS_ERR(ddata->pwr_reset)) {
> +                       dev_err(dev, "Failed to get Power Reset\n");
> +                       return PTR_ERR(ddata->pwr_reset);
> +               }
> +       }
> +
> +       ddata->clk = devm_clk_get(dev, NULL);
> +       if (IS_ERR(ddata->clk)) {
> +               dev_err(dev, "Failed to get clock\n");
> +               return PTR_ERR(ddata->clk);
> +       }
> +
> +       err = of_property_read_u32(np, "clock-frequency", &ddata->clk_rate);
> +       if (err) {
> +               dev_err(dev, "failed to get clock frequency\n");
> +               return err;
> +       }
> +
> +       ddata->boot_base = syscon_regmap_lookup_by_phandle(np, "st,syscfg");
> +       if (!ddata->boot_base) {
> +               dev_err(dev, "Boot base not found\n");
> +               return -EINVAL;
> +       }
> +
> +       err = of_property_read_u32_index(np, "st,syscfg", 1,
> +                                        &ddata->boot_offset);
> +       if (err) {
> +               dev_err(dev, "Boot offset not found\n");
> +               return -EINVAL;
> +       }
> +
> +       err = of_reserved_mem_device_init(dev);
> +       if (err) {
> +               dev_err(dev, "Failed to obtain shared memory\n");
> +               return err;
> +       }
> +
> +       err = clk_prepare(ddata->clk);
> +       if (err)
> +               dev_err(dev, "failed to get clock\n");
> +
> +       return err;
> +}
> +
> +static int st_rproc_probe(struct platform_device *pdev)
> +{
> +       struct device *dev = &pdev->dev;
> +       const struct of_device_id *match;
> +       struct st_rproc *ddata;
> +       struct device_node *np = dev->of_node;
> +       struct rproc *rproc;
> +       int enabled;
> +       int ret;
> +
> +       match = of_match_device(st_rproc_match, dev);
> +       if (!match || !match->data) {
> +               dev_err(dev, "No device match found\n");
> +               return -ENODEV;
> +       }
> +
> +       rproc = rproc_alloc(dev, np->name, &st_rproc_ops, NULL, sizeof(*ddata));
> +       if (!rproc)
> +               return -ENOMEM;
> +
> +       rproc->has_iommu = false;
> +       ddata = rproc->priv;
> +       ddata->config = (struct st_rproc_config *)match->data;
> +
> +       platform_set_drvdata(pdev, rproc);
> +
> +       ret = st_rproc_parse_dt(pdev);
> +       if (ret)
> +               goto free_rproc;
> +
> +       enabled = st_rproc_state(pdev);
> +       if (enabled < 0)
> +               goto free_rproc;
> +
> +       if (enabled) {
> +               atomic_inc(&rproc->power);
> +               rproc->state = RPROC_RUNNING;
> +       } else {
> +               clk_set_rate(ddata->clk, ddata->clk_rate);
> +       }
> +
> +       ret = rproc_add(rproc);
> +       if (ret)
> +               goto free_rproc;
> +
> +       return 0;
> +
> +free_rproc:
> +       rproc_put(rproc);
> +       return ret;
> +}
> +
> +static int st_rproc_remove(struct platform_device *pdev)
> +{
> +       struct rproc *rproc = platform_get_drvdata(pdev);
> +       struct st_rproc *ddata = rproc->priv;
> +
> +       rproc_del(rproc);
> +
> +       clk_disable_unprepare(ddata->clk);
> +
> +       of_reserved_mem_device_release(&pdev->dev);
> +
> +       rproc_put(rproc);
> +
> +       return 0;
> +}
> +
> +static struct platform_driver st_rproc_driver = {
> +       .probe = st_rproc_probe,
> +       .remove = st_rproc_remove,
> +       .driver = {
> +               .name = "st-rproc",
> +               .of_match_table = of_match_ptr(st_rproc_match),
> +       },
> +};
> +module_platform_driver(st_rproc_driver);
> +
> +MODULE_DESCRIPTION("ST Remote Processor Control Driver");
> +MODULE_AUTHOR("Ludovic Barre <ludovic.barre-qxv4g6HH51o@public.gmane.org>");
> +MODULE_LICENSE("GPL v2");
> --
> 1.9.1
>
> --
> 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
--
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

[RESEND v4 4/6] MAINTAINERS: Add ST's Remote Processor Driver to ARM/STI ARCHITECTURE

[Lee Jones]

Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 5f46784..322f5b4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1538,6 +1538,7 @@ F:	drivers/phy/phy-miphy365x.c
 F:	drivers/phy/phy-stih407-usb.c
 F:	drivers/phy/phy-stih41x-usb.c
 F:	drivers/pinctrl/pinctrl-st.c
+F:	drivers/remoteproc/st_remoteproc.c
 F:	drivers/reset/sti/
 F:	drivers/rtc/rtc-st-lpc.c
 F:	drivers/tty/serial/st-asc.c
-- 
1.9.1

[RESEND v4 5/6] ARM: STiH407: Add nodes for RemoteProc

[Lee Jones]

Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 arch/arm/boot/dts/stih407-family.dtsi | 40 +++++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)

diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
index 1e4e01925..15c20b6 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -650,5 +650,45 @@
 			mbox-name	= "st231_audio_video";
 			status		= "okay";
 		};
+
+		st231_gp0: st231-gp0@40000000 {
+			compatible	= "st,st231-rproc";
+			reg		= <0x40000000 0x01000000>;
+			resets		= <&softreset STIH407_ST231_GP0_SOFTRESET>;
+			reset-names	= "sw_reset";
+			clocks		= <&clk_s_c0_flexgen CLK_ST231_GP_0>;
+			clock-frequency	= <600000000>;
+			st,syscfg	= <&syscfg_core 0x22c>;
+		};
+
+		st231_gp1: st231-gp1@41000000 {
+			compatible	= "st,st231-rproc";
+			reg		= <0x41000000 0x01000000>;
+			resets		= <&softreset STIH407_ST231_GP1_SOFTRESET>;
+			reset-names	= "sw_reset";
+			clocks		= <&clk_s_c0_flexgen CLK_ST231_GP_1>;
+			clock-frequency = <600000000>;
+			st,syscfg	= <&syscfg_core 0x220>;
+		};
+
+		st231_audio: st231-audio@42000000 {
+			compatible	= "st,st231-rproc";
+			reg		= <0x42000000 0x01000000>;
+			resets		= <&softreset STIH407_ST231_AUD_SOFTRESET>;
+			reset-names	= "sw_reset";
+			clocks		= <&clk_s_c0_flexgen CLK_ST231_AUD_0>;
+			clock-frequency	= <600000000>;
+			st,syscfg	= <&syscfg_core 0x228>;
+		};
+
+		st231_dmu: st231-dmu@43000000 {
+			compatible	= "st,st231-rproc";
+			reg		= <0x43000000 0x01000000>;
+			resets		= <&softreset STIH407_ST231_DMU_SOFTRESET>;
+			reset-names	= "sw_reset";
+			clocks		= <&clk_s_c0_flexgen CLK_ST231_DMU>;
+			clock-frequency	= <600000000>;
+			st,syscfg	= <&syscfg_core 0x224>;
+		};
 	};
 };
-- 
1.9.1

[RESEND v4 6/6] ARM: STiH407: Move over to using the 'reserved-memory' API for obtaining DMA memory

[Lee Jones]

Doing so saves quite a bit of code in the driver.

For more information on the 'reserved-memory' bindings see:

  Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt

Suggested-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 arch/arm/boot/dts/stih407-family.dtsi | 46 +++++++++++++++++++++++++++++------
 1 file changed, 38 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
index 15c20b6..27b8efc 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -15,6 +15,36 @@
 	#address-cells = <1>;
 	#size-cells = <1>;
 
+	reserved-memory {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		gp0_reserved: rproc@40000000 {
+			compatible = "shared-dma-pool";
+			reg = <0x40000000 0x01000000>;
+			no-map;
+		};
+
+		gp1_reserved: rproc@41000000 {
+			compatible = "shared-dma-pool";
+			reg = <0x41000000 0x01000000>;
+			no-map;
+		};
+
+		audio_reserved: rproc@42000000 {
+			compatible = "shared-dma-pool";
+			reg = <0x42000000 0x01000000>;
+			no-map;
+		};
+
+		dmu_reserved: rproc@43000000 {
+			compatible = "shared-dma-pool";
+			reg = <0x43000000 0x01000000>;
+			no-map;
+		};
+	};
+
 	cpus {
 		#address-cells = <1>;
 		#size-cells = <0>;
@@ -651,9 +681,9 @@
 			status		= "okay";
 		};
 
-		st231_gp0: st231-gp0@40000000 {
+		st231_gp0: st231-gp0 {
 			compatible	= "st,st231-rproc";
-			reg		= <0x40000000 0x01000000>;
+			memory-region	= <&gp0_reserved>;
 			resets		= <&softreset STIH407_ST231_GP0_SOFTRESET>;
 			reset-names	= "sw_reset";
 			clocks		= <&clk_s_c0_flexgen CLK_ST231_GP_0>;
@@ -661,9 +691,9 @@
 			st,syscfg	= <&syscfg_core 0x22c>;
 		};
 
-		st231_gp1: st231-gp1@41000000 {
+		st231_gp1: st231-gp1 {
 			compatible	= "st,st231-rproc";
-			reg		= <0x41000000 0x01000000>;
+			memory-region	= <&gp1_reserved>;
 			resets		= <&softreset STIH407_ST231_GP1_SOFTRESET>;
 			reset-names	= "sw_reset";
 			clocks		= <&clk_s_c0_flexgen CLK_ST231_GP_1>;
@@ -671,9 +701,9 @@
 			st,syscfg	= <&syscfg_core 0x220>;
 		};
 
-		st231_audio: st231-audio@42000000 {
+		st231_audio: st231-audio {
 			compatible	= "st,st231-rproc";
-			reg		= <0x42000000 0x01000000>;
+			memory-region	= <&audio_reserved>;
 			resets		= <&softreset STIH407_ST231_AUD_SOFTRESET>;
 			reset-names	= "sw_reset";
 			clocks		= <&clk_s_c0_flexgen CLK_ST231_AUD_0>;
@@ -681,9 +711,9 @@
 			st,syscfg	= <&syscfg_core 0x228>;
 		};
 
-		st231_dmu: st231-dmu@43000000 {
+		st231_dmu: st231-dmu {
 			compatible	= "st,st231-rproc";
-			reg		= <0x43000000 0x01000000>;
+			memory-region	= <&dmu_reserved>;
 			resets		= <&softreset STIH407_ST231_DMU_SOFTRESET>;
 			reset-names	= "sw_reset";
 			clocks		= <&clk_s_c0_flexgen CLK_ST231_DMU>;
-- 
1.9.1

Re: [RESEND v4 0/6] remoteproc: Add driver for STMicroelectronics platforms

[Ohad Ben-Cohen]

Hi Lee,

On Tue, Nov 24, 2015 at 3:14 PM, Lee Jones <lee.jones@linaro.org> wrote:
> ST's platforms often have multiple co-processors (usually ST40s or ST231s)
> on-board.  This provides the Linux-side infrastructure to flash and boot
> them successfully.
>
> This set has been tested on an STiH410-B2120.

It would be nice if you could get at least one Reviewed-by tag coming
outside of ST (e.g., Suman or Bjorn who are actively using and
improving remoteproc).

>  arch/arm/boot/dts/stih407-family.dtsi              |  70 +++++

Since this is outside of remoteproc, please have it Acked, preferably
by ARM DT maintainer (Olof?).

Thanks,
Ohad.

Re: [RESEND v4 0/6] remoteproc: Add driver for STMicroelectronics platforms

[Lee Jones]

On Thu, 26 Nov 2015, Ohad Ben-Cohen wrote:
> On Tue, Nov 24, 2015 at 3:14 PM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> > ST's platforms often have multiple co-processors (usually ST40s or ST231s)
> > on-board.  This provides the Linux-side infrastructure to flash and boot
> > them successfully.
> >
> > This set has been tested on an STiH410-B2120.
> 
> It would be nice if you could get at least one Reviewed-by tag coming
> outside of ST (e.g., Suman or Bjorn who are actively using and
> improving remoteproc).

If you require reviews by these guys, shouldn't they be Maintainers?

> >  arch/arm/boot/dts/stih407-family.dtsi              |  70 +++++
> 
> Since this is outside of remoteproc, please have it Acked, preferably
> by ARM DT maintainer (Olof?).

The bindings have already been Acked by Rob.  So long as the DTS(I)
files conform to them, there should be no issue.  Please be aware that
the DTS(I) changes are applied to this set for your information only
and are not to be applied through the RemoteProc tree.  The usual
process to which we conform is that Maxime (the STi Maintainer) will
apply the DT changes *after* the main driver has been applied, in this
case by you.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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

Re: [RESEND v4 0/6] remoteproc: Add driver for STMicroelectronics platforms

[Ohad Ben-Cohen]

On Thu, Nov 26, 2015 at 11:10 AM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On Thu, 26 Nov 2015, Ohad Ben-Cohen wrote:
>> On Tue, Nov 24, 2015 at 3:14 PM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>> > ST's platforms often have multiple co-processors (usually ST40s or ST231s)
>> > on-board.  This provides the Linux-side infrastructure to flash and boot
>> > them successfully.
>> >
>> > This set has been tested on an STiH410-B2120.
>>
>> It would be nice if you could get at least one Reviewed-by tag coming
>> outside of ST (e.g., Suman or Bjorn who are actively using and
>> improving remoteproc).
>
> If you require reviews by these guys, shouldn't they be Maintainers?

Additional review isn't a requirement, but it's a plus.

> Please be aware that
> the DTS(I) changes are applied to this set for your information only
> and are not to be applied through the RemoteProc tree.  The usual
> process to which we conform is that Maxime (the STi Maintainer) will
> apply the DT changes *after* the main driver has been applied, in this
> case by you.

Ok, great, so I will not take patches 5 and 6.

Thanks,
Ohad.
--
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

Re: [RESEND v4 0/6] remoteproc: Add driver for STMicroelectronics platforms

[Bjorn Andersson]

On Thu, Nov 26, 2015 at 1:32 AM, Ohad Ben-Cohen <ohad-Ix1uc/W3ht7QT0dZR+AlfA@public.gmane.org> wrote:
> On Thu, Nov 26, 2015 at 11:10 AM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>> On Thu, 26 Nov 2015, Ohad Ben-Cohen wrote:
>>> On Tue, Nov 24, 2015 at 3:14 PM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>>> > ST's platforms often have multiple co-processors (usually ST40s or ST231s)
>>> > on-board.  This provides the Linux-side infrastructure to flash and boot
>>> > them successfully.
>>> >
>>> > This set has been tested on an STiH410-B2120.
>>>
>>> It would be nice if you could get at least one Reviewed-by tag coming
>>> outside of ST (e.g., Suman or Bjorn who are actively using and
>>> improving remoteproc).
>>
>> If you require reviews by these guys, shouldn't they be Maintainers?
>
> Additional review isn't a requirement, but it's a plus.
>
>> Please be aware that
>> the DTS(I) changes are applied to this set for your information only
>> and are not to be applied through the RemoteProc tree.  The usual
>> process to which we conform is that Maxime (the STi Maintainer) will
>> apply the DT changes *after* the main driver has been applied, in this
>> case by you.
>
> Ok, great, so I will not take patches 5 and 6.
>

I interpreted this as you picked patch 1-4 and didn't pay more
attention to them, but I can't find them in your kernel.org trees. So
I've looked through them again.

Please apply patch 1, 3 and 4 to your tree Ohad. I was unable to find
a v5 of patch 2, but it's unrelated so no need to wait for a new
version of that.

Regards,
Bjorn
--
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

Re: [RESEND v4 0/6] remoteproc: Add driver for STMicroelectronics platforms

[Ohad Ben-Cohen]

On Mon, Dec 28, 2015 at 8:41 PM, Bjorn Andersson <bjorn-UYDU3/A3LUY@public.gmane.org> wrote:
> I interpreted this as you picked patch 1-4 and didn't pay more
> attention to them, but I can't find them in your kernel.org trees. So
> I've looked through them again.
>
> Please apply patch 1, 3 and 4 to your tree Ohad. I was unable to find
> a v5 of patch 2, but it's unrelated so no need to wait for a new
> version of that.

I was under the impression that Lee plans to resubmit once the
discussion around patch 2 settles, so I haven't picked the series yet.

Lee please let me know - I can take 1/3/4 and wait for the new 2 as well.

Thanks,
Ohad.
--
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

Re: [RESEND v4 0/6] remoteproc: Add driver for STMicroelectronics platforms

[Lee Jones]

On Tue, 29 Dec 2015, Ohad Ben-Cohen wrote:

> On Mon, Dec 28, 2015 at 8:41 PM, Bjorn Andersson <bjorn@kryo.se> wrote:
> > I interpreted this as you picked patch 1-4 and didn't pay more
> > attention to them, but I can't find them in your kernel.org trees. So
> > I've looked through them again.
> >
> > Please apply patch 1, 3 and 4 to your tree Ohad. I was unable to find
> > a v5 of patch 2, but it's unrelated so no need to wait for a new
> > version of that.
> 
> I was under the impression that Lee plans to resubmit once the
> discussion around patch 2 settles, so I haven't picked the series yet.
> 
> Lee please let me know - I can take 1/3/4 and wait for the new 2 as well.

Yes, that's correct.  Will re-submit the set in a wee-mo.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog