From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Cl?ment Leger <cleger@kalrayinc.com>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>,
Ohad Ben-Cohen <ohad@wizery.com>,
Jonathan Corbet <corbet@lwn.net>, Shawn Guo <shawnguo@kernel.org>,
Sascha Hauer <s.hauer@pengutronix.de>,
linux-remoteproc <linux-remoteproc@vger.kernel.org>,
Pengutronix Kernel Team <kernel@pengutronix.de>,
Fabio Estevam <festevam@gmail.com>,
NXP Linux Team <linux-imx@nxp.com>,
Andy Gross <agross@kernel.org>,
Patrice Chotard <patrice.chotard@st.com>,
linux-doc <linux-doc@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
linux-arm-msm <linux-arm-msm@vger.kernel.org>,
Arnaud Pouliquen <arnaud.pouliquen@st.com>,
Loic PALLARDY <loic.pallardy@st.com>, s-anna <s-anna@ti.com>
Subject: Re: [PATCH v5 3/8] remoteproc: Use u64 type for boot_addr
Date: Tue, 10 Mar 2020 12:32:53 -0700 [thread overview]
Message-ID: <20200310193253.GL264362@yoga> (raw)
In-Reply-To: <1297722115.9030349.1583827151221.JavaMail.zimbra@kalray.eu>
On Tue 10 Mar 00:59 PDT 2020, Cl?ment Leger wrote:
>
>
> ----- On 9 Mar, 2020, at 20:52, Mathieu Poirier mathieu.poirier@linaro.org wrote:
>
> > On Mon, Mar 02, 2020 at 10:38:57AM +0100, Clement Leger wrote:
> >> elf64 entry is defined as a u64. Since boot_addr is used to store the
> >> elf entry point, change boot_addr type to u64 to support both elf32
> >> and elf64. In the same time, fix users that were using this variable.
> >>
> >> Signed-off-by: Clement Leger <cleger@kalray.eu>
> >> ---
> >> drivers/remoteproc/remoteproc_elf_loader.c | 2 +-
> >> drivers/remoteproc/remoteproc_internal.h | 2 +-
> >> drivers/remoteproc/st_remoteproc.c | 2 +-
> >> include/linux/remoteproc.h | 4 ++--
> >> 4 files changed, 5 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/remoteproc/remoteproc_elf_loader.c
> >> b/drivers/remoteproc/remoteproc_elf_loader.c
> >> index 606aae166eba..c2a9783cfb9a 100644
> >> --- a/drivers/remoteproc/remoteproc_elf_loader.c
> >> +++ b/drivers/remoteproc/remoteproc_elf_loader.c
> >> @@ -102,7 +102,7 @@ EXPORT_SYMBOL(rproc_elf_sanity_check);
> >> * Note that the boot address is not a configurable property of all remote
> >> * processors. Some will always boot at a specific hard-coded address.
> >> */
> >> -u32 rproc_elf_get_boot_addr(struct rproc *rproc, const struct firmware *fw)
> >> +u64 rproc_elf_get_boot_addr(struct rproc *rproc, const struct firmware *fw)
> >> {
> >> struct elf32_hdr *ehdr = (struct elf32_hdr *)fw->data;
> >>
> >> diff --git a/drivers/remoteproc/remoteproc_internal.h
> >> b/drivers/remoteproc/remoteproc_internal.h
> >> index 58580210575c..0deae5f237b8 100644
> >> --- a/drivers/remoteproc/remoteproc_internal.h
> >> +++ b/drivers/remoteproc/remoteproc_internal.h
> >> @@ -55,7 +55,7 @@ phys_addr_t rproc_va_to_pa(void *cpu_addr);
> >> int rproc_trigger_recovery(struct rproc *rproc);
> >>
> >> int rproc_elf_sanity_check(struct rproc *rproc, const struct firmware *fw);
> >> -u32 rproc_elf_get_boot_addr(struct rproc *rproc, const struct firmware *fw);
> >> +u64 rproc_elf_get_boot_addr(struct rproc *rproc, const struct firmware *fw);
> >> int rproc_elf_load_segments(struct rproc *rproc, const struct firmware *fw);
> >> int rproc_elf_load_rsc_table(struct rproc *rproc, const struct firmware *fw);
> >> struct resource_table *rproc_elf_find_loaded_rsc_table(struct rproc *rproc,
> >
> > The return type of function rproc_get_boot_addr() should also be changed from
> > u32 to u64. Or perhaps this is intentional to make sure rproc->bootaddr never
> > occupies more than 32bit?
>
> No, this is a mistake clearly. I haven't been able to test with a 64 bit
> boot address since our remote processors always boot in the 32 bits
> space. But since the elf64 boot address is on 64 bitsn this was a logical
> modification. I will fix that.
>
Sorry, I forgot to reply to this one. I fixed it up while applying the
patch.
Thanks,
Bjorn
> >
> >> diff --git a/drivers/remoteproc/st_remoteproc.c
> >> b/drivers/remoteproc/st_remoteproc.c
> >> index ee13d23b43a9..a3268d95a50e 100644
> >> --- a/drivers/remoteproc/st_remoteproc.c
> >> +++ b/drivers/remoteproc/st_remoteproc.c
> >> @@ -190,7 +190,7 @@ static int st_rproc_start(struct rproc *rproc)
> >> }
> >> }
> >>
> >> - dev_info(&rproc->dev, "Started from 0x%x\n", rproc->bootaddr);
> >> + dev_info(&rproc->dev, "Started from 0x%llx\n", rproc->bootaddr);
> >>
> >> return 0;
> >>
> >> diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
> >> index bee559330204..1683d6c386a6 100644
> >> --- a/include/linux/remoteproc.h
> >> +++ b/include/linux/remoteproc.h
> >> @@ -382,7 +382,7 @@ struct rproc_ops {
> >> struct rproc *rproc, const struct firmware *fw);
> >> int (*load)(struct rproc *rproc, const struct firmware *fw);
> >> int (*sanity_check)(struct rproc *rproc, const struct firmware *fw);
> >> - u32 (*get_boot_addr)(struct rproc *rproc, const struct firmware *fw);
> >> + u64 (*get_boot_addr)(struct rproc *rproc, const struct firmware *fw);
> >> };
> >>
> >> /**
> >> @@ -498,7 +498,7 @@ struct rproc {
> >> int num_traces;
> >> struct list_head carveouts;
> >> struct list_head mappings;
> >> - u32 bootaddr;
> >> + u64 bootaddr;
> >> struct list_head rvdevs;
> >> struct list_head subdevs;
> >> struct idr notifyids;
> >> --
> >> 2.15.0.276.g89ea799
WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Cl?ment Leger <cleger@kalrayinc.com>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>,
Ohad Ben-Cohen <ohad@wizery.com>,
Jonathan Corbet <corbet@lwn.net>, Shawn Guo <shawnguo@kernel.org>,
Sascha Hauer <s.hauer@pengutronix.de>,
linux-remoteproc <linux-remoteproc@vger.kernel.org>,
Pengutronix Kernel Team <kernel@pengutronix.de>,
Fabio Estevam <festevam@gmail.com>,
NXP Linux Team <linux-imx@nxp.com>,
Andy Gross <agross@kernel.org>,
Patrice Chotard <patrice.chotard@st.com>,
linux-doc <linux-doc@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
linux-arm-msm <linux-arm-msm@vger.kernel.org>,
Arnaud Pouliquen <arnaud.pouliquen@st.com>,
Loic PALLARDY <loic.pallardy@st.com>, s-anna <s-anna@ti.com>
Subject: Re: [PATCH v5 3/8] remoteproc: Use u64 type for boot_addr
Date: Tue, 10 Mar 2020 12:32:57 -0700 [thread overview]
Message-ID: <20200310193253.GL264362@yoga> (raw)
In-Reply-To: <1297722115.9030349.1583827151221.JavaMail.zimbra@kalray.eu>
On Tue 10 Mar 00:59 PDT 2020, Cl?ment Leger wrote:
>
>
> ----- On 9 Mar, 2020, at 20:52, Mathieu Poirier mathieu.poirier@linaro.org wrote:
>
> > On Mon, Mar 02, 2020 at 10:38:57AM +0100, Clement Leger wrote:
> >> elf64 entry is defined as a u64. Since boot_addr is used to store the
> >> elf entry point, change boot_addr type to u64 to support both elf32
> >> and elf64. In the same time, fix users that were using this variable.
> >>
> >> Signed-off-by: Clement Leger <cleger@kalray.eu>
> >> ---
> >> drivers/remoteproc/remoteproc_elf_loader.c | 2 +-
> >> drivers/remoteproc/remoteproc_internal.h | 2 +-
> >> drivers/remoteproc/st_remoteproc.c | 2 +-
> >> include/linux/remoteproc.h | 4 ++--
> >> 4 files changed, 5 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/remoteproc/remoteproc_elf_loader.c
> >> b/drivers/remoteproc/remoteproc_elf_loader.c
> >> index 606aae166eba..c2a9783cfb9a 100644
> >> --- a/drivers/remoteproc/remoteproc_elf_loader.c
> >> +++ b/drivers/remoteproc/remoteproc_elf_loader.c
> >> @@ -102,7 +102,7 @@ EXPORT_SYMBOL(rproc_elf_sanity_check);
> >> * Note that the boot address is not a configurable property of all remote
> >> * processors. Some will always boot at a specific hard-coded address.
> >> */
> >> -u32 rproc_elf_get_boot_addr(struct rproc *rproc, const struct firmware *fw)
> >> +u64 rproc_elf_get_boot_addr(struct rproc *rproc, const struct firmware *fw)
> >> {
> >> struct elf32_hdr *ehdr = (struct elf32_hdr *)fw->data;
> >>
> >> diff --git a/drivers/remoteproc/remoteproc_internal.h
> >> b/drivers/remoteproc/remoteproc_internal.h
> >> index 58580210575c..0deae5f237b8 100644
> >> --- a/drivers/remoteproc/remoteproc_internal.h
> >> +++ b/drivers/remoteproc/remoteproc_internal.h
> >> @@ -55,7 +55,7 @@ phys_addr_t rproc_va_to_pa(void *cpu_addr);
> >> int rproc_trigger_recovery(struct rproc *rproc);
> >>
> >> int rproc_elf_sanity_check(struct rproc *rproc, const struct firmware *fw);
> >> -u32 rproc_elf_get_boot_addr(struct rproc *rproc, const struct firmware *fw);
> >> +u64 rproc_elf_get_boot_addr(struct rproc *rproc, const struct firmware *fw);
> >> int rproc_elf_load_segments(struct rproc *rproc, const struct firmware *fw);
> >> int rproc_elf_load_rsc_table(struct rproc *rproc, const struct firmware *fw);
> >> struct resource_table *rproc_elf_find_loaded_rsc_table(struct rproc *rproc,
> >
> > The return type of function rproc_get_boot_addr() should also be changed from
> > u32 to u64. Or perhaps this is intentional to make sure rproc->bootaddr never
> > occupies more than 32bit?
>
> No, this is a mistake clearly. I haven't been able to test with a 64 bit
> boot address since our remote processors always boot in the 32 bits
> space. But since the elf64 boot address is on 64 bitsn this was a logical
> modification. I will fix that.
>
Sorry, I forgot to reply to this one. I fixed it up while applying the
patch.
Thanks,
Bjorn
> >
> >> diff --git a/drivers/remoteproc/st_remoteproc.c
> >> b/drivers/remoteproc/st_remoteproc.c
> >> index ee13d23b43a9..a3268d95a50e 100644
> >> --- a/drivers/remoteproc/st_remoteproc.c
> >> +++ b/drivers/remoteproc/st_remoteproc.c
> >> @@ -190,7 +190,7 @@ static int st_rproc_start(struct rproc *rproc)
> >> }
> >> }
> >>
> >> - dev_info(&rproc->dev, "Started from 0x%x\n", rproc->bootaddr);
> >> + dev_info(&rproc->dev, "Started from 0x%llx\n", rproc->bootaddr);
> >>
> >> return 0;
> >>
> >> diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
> >> index bee559330204..1683d6c386a6 100644
> >> --- a/include/linux/remoteproc.h
> >> +++ b/include/linux/remoteproc.h
> >> @@ -382,7 +382,7 @@ struct rproc_ops {
> >> struct rproc *rproc, const struct firmware *fw);
> >> int (*load)(struct rproc *rproc, const struct firmware *fw);
> >> int (*sanity_check)(struct rproc *rproc, const struct firmware *fw);
> >> - u32 (*get_boot_addr)(struct rproc *rproc, const struct firmware *fw);
> >> + u64 (*get_boot_addr)(struct rproc *rproc, const struct firmware *fw);
> >> };
> >>
> >> /**
> >> @@ -498,7 +498,7 @@ struct rproc {
> >> int num_traces;
> >> struct list_head carveouts;
> >> struct list_head mappings;
> >> - u32 bootaddr;
> >> + u64 bootaddr;
> >> struct list_head rvdevs;
> >> struct list_head subdevs;
> >> struct idr notifyids;
> >> --
> >> 2.15.0.276.g89ea799
WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Cl?ment Leger <cleger@kalrayinc.com>
Cc: Ohad Ben-Cohen <ohad@wizery.com>,
Arnaud Pouliquen <arnaud.pouliquen@st.com>,
Loic PALLARDY <loic.pallardy@st.com>,
Mathieu Poirier <mathieu.poirier@linaro.org>,
Jonathan Corbet <corbet@lwn.net>,
Fabio Estevam <festevam@gmail.com>,
Sascha Hauer <s.hauer@pengutronix.de>,
linux-doc <linux-doc@vger.kernel.org>,
linux-remoteproc <linux-remoteproc@vger.kernel.org>,
Patrice Chotard <patrice.chotard@st.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
Andy Gross <agross@kernel.org>,
NXP Linux Team <linux-imx@nxp.com>,
Pengutronix Kernel Team <kernel@pengutronix.de>,
linux-arm-msm <linux-arm-msm@vger.kernel.org>,
s-anna <s-anna@ti.com>, Shawn Guo <shawnguo@kernel.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v5 3/8] remoteproc: Use u64 type for boot_addr
Date: Tue, 10 Mar 2020 12:32:53 -0700 [thread overview]
Message-ID: <20200310193253.GL264362@yoga> (raw)
In-Reply-To: <1297722115.9030349.1583827151221.JavaMail.zimbra@kalray.eu>
On Tue 10 Mar 00:59 PDT 2020, Cl?ment Leger wrote:
>
>
> ----- On 9 Mar, 2020, at 20:52, Mathieu Poirier mathieu.poirier@linaro.org wrote:
>
> > On Mon, Mar 02, 2020 at 10:38:57AM +0100, Clement Leger wrote:
> >> elf64 entry is defined as a u64. Since boot_addr is used to store the
> >> elf entry point, change boot_addr type to u64 to support both elf32
> >> and elf64. In the same time, fix users that were using this variable.
> >>
> >> Signed-off-by: Clement Leger <cleger@kalray.eu>
> >> ---
> >> drivers/remoteproc/remoteproc_elf_loader.c | 2 +-
> >> drivers/remoteproc/remoteproc_internal.h | 2 +-
> >> drivers/remoteproc/st_remoteproc.c | 2 +-
> >> include/linux/remoteproc.h | 4 ++--
> >> 4 files changed, 5 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/remoteproc/remoteproc_elf_loader.c
> >> b/drivers/remoteproc/remoteproc_elf_loader.c
> >> index 606aae166eba..c2a9783cfb9a 100644
> >> --- a/drivers/remoteproc/remoteproc_elf_loader.c
> >> +++ b/drivers/remoteproc/remoteproc_elf_loader.c
> >> @@ -102,7 +102,7 @@ EXPORT_SYMBOL(rproc_elf_sanity_check);
> >> * Note that the boot address is not a configurable property of all remote
> >> * processors. Some will always boot at a specific hard-coded address.
> >> */
> >> -u32 rproc_elf_get_boot_addr(struct rproc *rproc, const struct firmware *fw)
> >> +u64 rproc_elf_get_boot_addr(struct rproc *rproc, const struct firmware *fw)
> >> {
> >> struct elf32_hdr *ehdr = (struct elf32_hdr *)fw->data;
> >>
> >> diff --git a/drivers/remoteproc/remoteproc_internal.h
> >> b/drivers/remoteproc/remoteproc_internal.h
> >> index 58580210575c..0deae5f237b8 100644
> >> --- a/drivers/remoteproc/remoteproc_internal.h
> >> +++ b/drivers/remoteproc/remoteproc_internal.h
> >> @@ -55,7 +55,7 @@ phys_addr_t rproc_va_to_pa(void *cpu_addr);
> >> int rproc_trigger_recovery(struct rproc *rproc);
> >>
> >> int rproc_elf_sanity_check(struct rproc *rproc, const struct firmware *fw);
> >> -u32 rproc_elf_get_boot_addr(struct rproc *rproc, const struct firmware *fw);
> >> +u64 rproc_elf_get_boot_addr(struct rproc *rproc, const struct firmware *fw);
> >> int rproc_elf_load_segments(struct rproc *rproc, const struct firmware *fw);
> >> int rproc_elf_load_rsc_table(struct rproc *rproc, const struct firmware *fw);
> >> struct resource_table *rproc_elf_find_loaded_rsc_table(struct rproc *rproc,
> >
> > The return type of function rproc_get_boot_addr() should also be changed from
> > u32 to u64. Or perhaps this is intentional to make sure rproc->bootaddr never
> > occupies more than 32bit?
>
> No, this is a mistake clearly. I haven't been able to test with a 64 bit
> boot address since our remote processors always boot in the 32 bits
> space. But since the elf64 boot address is on 64 bitsn this was a logical
> modification. I will fix that.
>
Sorry, I forgot to reply to this one. I fixed it up while applying the
patch.
Thanks,
Bjorn
> >
> >> diff --git a/drivers/remoteproc/st_remoteproc.c
> >> b/drivers/remoteproc/st_remoteproc.c
> >> index ee13d23b43a9..a3268d95a50e 100644
> >> --- a/drivers/remoteproc/st_remoteproc.c
> >> +++ b/drivers/remoteproc/st_remoteproc.c
> >> @@ -190,7 +190,7 @@ static int st_rproc_start(struct rproc *rproc)
> >> }
> >> }
> >>
> >> - dev_info(&rproc->dev, "Started from 0x%x\n", rproc->bootaddr);
> >> + dev_info(&rproc->dev, "Started from 0x%llx\n", rproc->bootaddr);
> >>
> >> return 0;
> >>
> >> diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
> >> index bee559330204..1683d6c386a6 100644
> >> --- a/include/linux/remoteproc.h
> >> +++ b/include/linux/remoteproc.h
> >> @@ -382,7 +382,7 @@ struct rproc_ops {
> >> struct rproc *rproc, const struct firmware *fw);
> >> int (*load)(struct rproc *rproc, const struct firmware *fw);
> >> int (*sanity_check)(struct rproc *rproc, const struct firmware *fw);
> >> - u32 (*get_boot_addr)(struct rproc *rproc, const struct firmware *fw);
> >> + u64 (*get_boot_addr)(struct rproc *rproc, const struct firmware *fw);
> >> };
> >>
> >> /**
> >> @@ -498,7 +498,7 @@ struct rproc {
> >> int num_traces;
> >> struct list_head carveouts;
> >> struct list_head mappings;
> >> - u32 bootaddr;
> >> + u64 bootaddr;
> >> struct list_head rvdevs;
> >> struct list_head subdevs;
> >> struct idr notifyids;
> >> --
> >> 2.15.0.276.g89ea799
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-03-10 19:32 UTC|newest]
Thread overview: 164+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-02 8:28 [RFC PATCH] rproc: Add elf64 support in elf loader Clément Leger
2019-05-07 12:09 ` Clément Leger
2019-05-07 13:37 ` Arnaud Pouliquen
2019-05-09 8:59 ` Clément Leger
2019-08-19 11:45 ` [PATCH] " Clement Leger
2019-09-13 10:58 ` Clément Leger
2019-10-04 8:27 ` Clément Leger
2019-10-04 18:42 ` [PATCH v2] remoteproc: " Clement Leger
2020-01-09 9:31 ` Clément Leger
2020-01-24 0:53 ` Mathieu Poirier
2020-01-24 8:24 ` Clément Leger
2020-01-24 18:10 ` Mathieu Poirier
2020-01-24 18:10 ` Mathieu Poirier
2020-01-24 21:58 ` Mathieu Poirier
2020-01-24 21:58 ` Mathieu Poirier
2020-01-27 8:33 ` Clément Leger
2020-01-28 17:14 ` Mathieu Poirier
2020-01-29 8:55 ` Clément Leger
2020-01-29 16:30 ` Mathieu Poirier
2020-01-29 16:30 ` Mathieu Poirier
2020-02-04 14:33 ` [PATCH v2 1/2] remoteproc: Use u64 len for da_to_va Clement Leger
2020-02-04 14:33 ` Clement Leger
2020-02-04 14:33 ` [PATCH v2 2/2] remoteproc: Add elf64 support in elf loader Clement Leger
2020-02-04 14:33 ` Clement Leger
2020-02-04 16:27 ` [PATCH v2 1/2] remoteproc: Use u64 len for da_to_va Arnaud POULIQUEN
2020-02-04 16:27 ` Arnaud POULIQUEN
2020-02-04 16:27 ` Arnaud POULIQUEN
2020-02-04 17:10 ` Clément Leger
2020-02-04 17:10 ` Clément Leger
2020-02-04 17:42 ` Arnaud POULIQUEN
2020-02-04 17:42 ` Arnaud POULIQUEN
2020-02-04 17:42 ` Arnaud POULIQUEN
2020-02-04 17:44 ` [PATCH v3 0/2] remoteproc: Add elf64 support to elf loader Clement Leger
2020-02-04 17:44 ` Clement Leger
2020-02-04 17:44 ` [PATCH v3 1/2] remoteproc: Use u64 len for da_to_va Clement Leger
2020-02-04 17:44 ` Clement Leger
2020-02-05 21:06 ` Mathieu Poirier
2020-02-05 21:06 ` Mathieu Poirier
2020-02-04 17:44 ` [PATCH v3 2/2] remoteproc: Add elf64 support in elf loader Clement Leger
2020-02-04 17:44 ` Clement Leger
2020-02-05 22:49 ` Mathieu Poirier
2020-02-05 22:49 ` Mathieu Poirier
2020-02-06 8:37 ` Clément Leger
2020-02-06 8:37 ` Clément Leger
2020-02-06 15:05 ` Clément Leger
2020-02-06 15:05 ` Clément Leger
2020-02-06 17:48 ` Mathieu Poirier
2020-02-06 17:48 ` Mathieu Poirier
2020-02-06 17:48 ` Mathieu Poirier
2020-02-07 7:57 ` Clément Leger
2020-02-07 7:57 ` Clément Leger
2020-02-10 16:22 ` [PATCH v4 0/5] remoteproc: Add elf64 support Clement Leger
2020-02-10 16:22 ` Clement Leger
2020-02-10 16:22 ` [PATCH v4 1/5] remoteproc: Use u64 len for da_to_va Clement Leger
2020-02-10 16:22 ` Clement Leger
2020-02-11 15:53 ` Arnaud POULIQUEN
2020-02-11 15:53 ` Arnaud POULIQUEN
2020-02-11 15:53 ` Arnaud POULIQUEN
2020-02-11 16:39 ` Clément Leger
2020-02-11 16:39 ` Clément Leger
2020-02-11 17:24 ` Arnaud POULIQUEN
2020-02-11 17:24 ` Arnaud POULIQUEN
2020-02-11 22:37 ` Mathieu Poirier
2020-02-11 22:37 ` Mathieu Poirier
2020-02-11 22:37 ` Mathieu Poirier
2020-02-12 10:37 ` Clément Leger
2020-02-12 10:37 ` Clément Leger
2020-02-12 21:59 ` Mathieu Poirier
2020-02-12 21:59 ` Mathieu Poirier
2020-02-18 10:10 ` Clément Leger
2020-02-18 10:10 ` Clément Leger
2020-02-18 17:01 ` Mathieu Poirier
2020-02-18 17:01 ` Mathieu Poirier
2020-02-10 16:22 ` [PATCH v4 2/5] remoteproc: Use u64 type for boot_addr Clement Leger
2020-02-10 16:22 ` Clement Leger
2020-02-10 16:22 ` [PATCH v4 3/5] remoteproc: Add elf helpers to access elf64 and elf32 fields Clement Leger
2020-02-10 16:22 ` Clement Leger
2020-02-10 16:22 ` [PATCH v4 4/5] remoteproc: Add elf64 support in elf loader Clement Leger
2020-02-10 16:22 ` Clement Leger
2020-02-10 16:22 ` [PATCH v4 5/5] remoteproc: Adapt coredump to generate correct elf type Clement Leger
2020-02-10 16:22 ` Clement Leger
2020-02-11 23:11 ` Mathieu Poirier
2020-02-11 23:11 ` Mathieu Poirier
2020-02-11 15:57 ` [PATCH v4 0/5] remoteproc: Add elf64 support Arnaud POULIQUEN
2020-02-11 15:57 ` Arnaud POULIQUEN
2020-02-11 15:57 ` Arnaud POULIQUEN
2020-02-11 23:12 ` Mathieu Poirier
2020-02-11 23:12 ` Mathieu Poirier
2020-02-12 8:15 ` Arnaud POULIQUEN
2020-02-12 8:15 ` Arnaud POULIQUEN
2020-02-12 8:15 ` Arnaud POULIQUEN
2020-03-02 9:38 ` [PATCH v5 0/8] " Clement Leger
2020-03-02 9:38 ` Clement Leger
2020-03-02 9:38 ` [PATCH v5 1/8] remoteproc: Use size_t type for len in da_to_va Clement Leger
2020-03-02 9:38 ` Clement Leger
2020-03-02 23:06 ` Bjorn Andersson
2020-03-02 23:06 ` Bjorn Andersson
2020-03-02 23:06 ` Bjorn Andersson
2020-03-09 17:52 ` Mathieu Poirier
2020-03-09 17:52 ` Mathieu Poirier
2020-03-27 7:37 ` Oleksij Rempel
2020-03-27 7:37 ` Oleksij Rempel
2020-03-02 9:38 ` [PATCH v5 2/8] remoteproc: Use size_t instead of int for rproc_mem_entry len Clement Leger
2020-03-02 9:38 ` Clement Leger
2020-03-02 23:07 ` Bjorn Andersson
2020-03-02 23:07 ` Bjorn Andersson
2020-03-02 23:07 ` Bjorn Andersson
2020-03-09 19:21 ` Mathieu Poirier
2020-03-09 19:21 ` Mathieu Poirier
2020-03-02 9:38 ` [PATCH v5 3/8] remoteproc: Use u64 type for boot_addr Clement Leger
2020-03-02 9:38 ` Clement Leger
2020-03-02 23:08 ` Bjorn Andersson
2020-03-02 23:08 ` Bjorn Andersson
2020-03-02 23:08 ` Bjorn Andersson
2020-03-09 19:52 ` Mathieu Poirier
2020-03-09 19:52 ` Mathieu Poirier
2020-03-10 7:59 ` Clément Leger
2020-03-10 7:59 ` Clément Leger
2020-03-10 19:32 ` Bjorn Andersson [this message]
2020-03-10 19:32 ` Bjorn Andersson
2020-03-10 19:32 ` Bjorn Andersson
2020-03-02 9:38 ` [PATCH v5 4/8] remoteproc: Add elf helpers to access elf64 and elf32 fields Clement Leger
2020-03-02 9:38 ` Clement Leger
2020-03-02 23:12 ` Bjorn Andersson
2020-03-02 23:12 ` Bjorn Andersson
2020-03-02 23:12 ` Bjorn Andersson
2020-03-09 19:56 ` Mathieu Poirier
2020-03-09 19:56 ` Mathieu Poirier
2020-03-02 9:38 ` [PATCH v5 5/8] remoteproc: Rename rproc_elf_sanity_check for elf32 Clement Leger
2020-03-02 9:38 ` Clement Leger
2020-03-02 23:13 ` Bjorn Andersson
2020-03-02 23:13 ` Bjorn Andersson
2020-03-02 23:13 ` Bjorn Andersson
2020-03-03 8:02 ` Clément Leger
2020-03-03 8:02 ` Clément Leger
2020-03-10 0:00 ` Bjorn Andersson
2020-03-10 0:00 ` Bjorn Andersson
2020-03-10 0:00 ` Bjorn Andersson
2020-03-10 15:20 ` Mathieu Poirier
2020-03-10 15:20 ` Mathieu Poirier
2020-03-10 15:20 ` Mathieu Poirier
2020-03-10 15:38 ` Clément Leger
2020-03-10 15:38 ` Clément Leger
2020-03-10 19:18 ` Mathieu Poirier
2020-03-10 19:18 ` Mathieu Poirier
2020-03-10 19:30 ` Bjorn Andersson
2020-03-10 19:30 ` Bjorn Andersson
2020-03-10 19:30 ` Bjorn Andersson
2020-03-02 9:39 ` [PATCH v5 6/8] remoteproc: Add elf64 support in elf loader Clement Leger
2020-03-02 9:39 ` Clement Leger
2020-03-02 9:39 ` [PATCH v5 7/8] remoteproc: Allow overriding only sanity_check Clement Leger
2020-03-02 9:39 ` Clement Leger
2020-03-02 9:39 ` [PATCH v5 8/8] remoteproc: Adapt coredump to generate correct elf type Clement Leger
2020-03-02 9:39 ` Clement Leger
2020-03-03 22:01 ` Bjorn Andersson
2020-03-03 22:01 ` Bjorn Andersson
2020-03-03 22:01 ` Bjorn Andersson
2020-03-09 20:32 ` Mathieu Poirier
2020-03-09 20:32 ` Mathieu Poirier
2020-03-09 23:57 ` Bjorn Andersson
2020-03-09 23:57 ` Bjorn Andersson
2020-03-09 23:57 ` Bjorn Andersson
2020-03-10 8:12 ` Clément Leger
2020-03-10 8:12 ` Clément Leger
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=20200310193253.GL264362@yoga \
--to=bjorn.andersson@linaro.org \
--cc=agross@kernel.org \
--cc=arnaud.pouliquen@st.com \
--cc=cleger@kalrayinc.com \
--cc=corbet@lwn.net \
--cc=festevam@gmail.com \
--cc=kernel@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=loic.pallardy@st.com \
--cc=mathieu.poirier@linaro.org \
--cc=ohad@wizery.com \
--cc=patrice.chotard@st.com \
--cc=s-anna@ti.com \
--cc=s.hauer@pengutronix.de \
--cc=shawnguo@kernel.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.