Re: [PATCH v13 2/7] remoteproc: Add TEE support

[Mathieu Poirier]

On Mon, Nov 04, 2024 at 02:35:10PM +0100, Arnaud Pouliquen wrote:
> Add a remoteproc TEE (Trusted Execution Environment) driver
> that will be probed by the TEE bus. If the associated Trusted
> application is supported on secure part this driver offers a client
> interface to load a firmware by the secure part.
> This firmware could be authenticated by the secure trusted application.
> 
> Signed-off-by: Arnaud Pouliquen 
> ---
> Updates from version V11:
> - rename structures, functions, and variables from "tee_rproc_xxx" to
>   "rproc_tee_xxx",
> - update rproc_tee_register to return an error instead of
>   "struct rproc_tee *" pointer,
> - update rproc_tee_unregister argument from "struct rproc_tee *trproc"
>   to "struct rproc *rproc",
> - reword MODULE_DESCRIPTION.
> ---
>  drivers/remoteproc/Kconfig  |  10 +
>  drivers/remoteproc/Makefile |   1 +
>  drivers/remoteproc/remoteproc_tee.c | 510 
>  include/linux/remoteproc.h  |   4 +
>  include/linux/remoteproc_tee.h  | 105 ++
>  5 files changed, 630 insertions(+)
>  create mode 100644 drivers/remoteproc/remoteproc_tee.c
>  create mode 100644 include/linux/remoteproc_tee.h
> 
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index 955e4e38477e..d0284220a194 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -23,6 +23,16 @@ config REMOTEPROC_CDEV
>  
> It's safe to say N if you don't want to use this interface.
>  
> +config REMOTEPROC_TEE
> + tristate "Remoteproc support by a TEE application"

Tristate?  Didn't we agree this would be either compiled in or out, but not as a
module?

> + depends on OPTEE
> + help
> +   Support a remote processor with a TEE application. The Trusted
> +   Execution Context is responsible for loading the trusted firmware
> +   image and managing the remote processor's lifecycle.
> +
> +   It's safe to say N if you don't want to use remoteproc TEE.
> +
>  config IMX_REMOTEPROC
>   tristate "i.MX remoteproc support"
>   depends on ARCH_MXC
> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> index 5ff4e2fee4ab..f77e0abe8349 100644
> --- a/drivers/remoteproc/Makefile
> +++ b/drivers/remoteproc/Makefile
> @@ -11,6 +11,7 @@ remoteproc-y+= 
> remoteproc_sysfs.o
>  remoteproc-y += remoteproc_virtio.o
>  remoteproc-y += remoteproc_elf_loader.o
>  obj-$(CONFIG_REMOTEPROC_CDEV)+= remoteproc_cdev.o
> +obj-$(CONFIG_REMOTEPROC_TEE) += remoteproc_tee.o
>  obj-$(CONFIG_IMX_REMOTEPROC) += imx_rproc.o
>  obj-$(CONFIG_IMX_DSP_REMOTEPROC) += imx_dsp_rproc.o
>  obj-$(CONFIG_INGENIC_VPU_RPROC)  += ingenic_rproc.o
> diff --git a/drivers/remoteproc/remoteproc_tee.c 
> b/drivers/remoteproc/remoteproc_tee.c
> new file mode 100644
> index ..f258b9304daf
> --- /dev/null
> +++ b/drivers/remoteproc/remoteproc_tee.c
> @@ -0,0 +1,510 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) STMicroelectronics 2024
> + * Author: Arnaud Pouliquen 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define MAX_TEE_PARAM_ARRAY_MEMBER   4
> +
> +/*
> + * Authentication of the firmware and load in the remote processor memory
> + *
> + * [in]  params[0].value.a:  unique 32bit identifier of the remote processor
> + * [in]   params[1].memref:  buffer containing the image of the 
> buffer
> + */
> +#define TA_RPROC_FW_CMD_LOAD_FW  1
> +
> +/*
> + * Start the remote processor
> + *
> + * [in]  params[0].value.a:  unique 32bit identifier of the remote processor
> + */
> +#define TA_RPROC_FW_CMD_START_FW 2
> +
> +/*
> + * Stop the remote processor
> + *
> + * [in]  params[0].value.a:  unique 32bit identifier of the remote processor
> + */
> +#define TA_RPROC_FW_CMD_STOP_FW  3
> +
> +/*
> + * Return the address of the resource table, or 0 if not found
> + * No check is done to verify that the address returned is accessible by
> + * the non secure context. If the resource table is loaded in a protected
> + * memory the access by the non secure context will lead to a data abort.
> + *
> + * [in]  params[0].value.a:  unique 32bit identifier of the remote processor
> + * [out]  params[1].value.a: 32bit LSB resource table memory address
> + * [out]  params[1].value.b: 32bit MSB resource table memory address
> + * [out]  params[2].value.a: 32bit LSB resource table memory size
> + * [out]  params[2].value.b: 32bit MSB resource table memory size
> + */
> +#define TA_RPROC_FW_CMD_GET_RSC_TABLE4
> +
> +/*
> + * Return the address of the core dump
> + *
> + * [in]  params[0].value.a:  unique 32bit identifier of the remote processor
> + * [out] params[1].memref:   address of the core dump image if exist,
> + *   else return Nu

Re: [PATCH 1/3] remoteproc: k3-r5: Use IO memset to clear TCMs

[Mathieu Poirier]

I have applied all 3 patches in this set.

Thanks,
Mathieu

On Mon, Oct 21, 2024 at 03:45:55PM -0500, Andrew Davis wrote:
> While it should be safe to use normal memset() on these memories as they
> are mapped as Normal Non-Cached, using the memset_io() provides stronger
> guarantees on access alignment and fixes a sparse check warning. Switch
> to memset_io() here.
> 
> Signed-off-by: Andrew Davis 
> ---
>  drivers/remoteproc/ti_k3_r5_remoteproc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c 
> b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> index 2f996a962f557..e1fe85e5eba6a 100644
> --- a/drivers/remoteproc/ti_k3_r5_remoteproc.c
> +++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> @@ -487,10 +487,10 @@ static int k3_r5_rproc_prepare(struct rproc *rproc)
>* can be effective on all TCM addresses.
>*/
>   dev_dbg(dev, "zeroing out ATCM memory\n");
> - memset(core->mem[0].cpu_addr, 0x00, core->mem[0].size);
> + memset_io(core->mem[0].cpu_addr, 0x00, core->mem[0].size);
>  
>   dev_dbg(dev, "zeroing out BTCM memory\n");
> - memset(core->mem[1].cpu_addr, 0x00, core->mem[1].size);
> + memset_io(core->mem[1].cpu_addr, 0x00, core->mem[1].size);
>  
>   return 0;
>  }
> -- 
> 2.39.2
> 

Re: [PATCH v3] remoteproc: Add a new remoteproc state RPROC_DEFUNCT

[Mathieu Poirier]

On Fri, Oct 25, 2024 at 01:40:45PM +0530, Mukesh Ojha wrote:
> On Mon, Oct 21, 2024 at 09:12:47AM -0600, Mathieu Poirier wrote:
> > Hi Mukesh,
> > 
> > On Wed, Oct 16, 2024 at 10:25:46AM +0530, Mukesh Ojha wrote:
> > > Multiple call to glink_subdev_stop() for the same remoteproc can happen
> > > if rproc_stop() fails from Process-A that leaves the rproc state to
> > > RPROC_CRASHED state later a call to recovery_store from user space in
> > > Process B triggers rproc_trigger_recovery() of the same remoteproc to
> > > recover it results in NULL pointer dereference issue in
> > > qcom_glink_smem_unregister().
> > > 
> > > There is other side to this issue if we want to fix this via adding a
> > > NULL check on glink->edge which does not guarantees that the remoteproc
> > > will recover in second call from Process B as it has failed in the first
> > > Process A during SMC shutdown call and may again fail at the same call
> > > and rproc can not recover for such case.
> > > 
> > > Add a new rproc state RPROC_DEFUNCT i.e., non recoverable state of
> > > remoteproc and the only way to recover from it via system restart.
> > > 
> > >   Process-A   Process-B
> > > 
> > >   fatal error interrupt happens
> > > 
> > >   rproc_crash_handler_work()
> > > mutex_lock_interruptible(&rproc->lock);
> > > ...
> > > 
> > >rproc->state = RPROC_CRASHED;
> > > ...
> > > mutex_unlock(&rproc->lock);
> > > 
> > > rproc_trigger_recovery()
> > >  mutex_lock_interruptible(&rproc->lock);
> > > 
> > >   adsp_stop()
> > >   qcom_q6v5_pas 20c0.remoteproc: failed to shutdown: -22
> > >   remoteproc remoteproc3: can't stop rproc: -22
> > >  mutex_unlock(&rproc->lock);
> > 
> > Ok, that can happen.
> > 
> > > 
> > >   echo enabled > 
> > > /sys/class/remoteproc/remoteprocX/recovery
> > >   recovery_store()
> > >rproc_trigger_recovery()
> > > 
> > > mutex_lock_interruptible(&rproc->lock);
> > >  rproc_stop()
> > >   glink_subdev_stop()
> > > 
> > > qcom_glink_smem_unregister() ==|
> > >   
> > >|
> > >   
> > >V
> > 
> > I am missing some information here but I will _assume_ this is caused by
> > glink->edge being set to NULL [1] when glink_subdev_stop() is first called 
> > by
> > process A.  Instead of adding a new state to the core I think a better idea
> > would be to add a check for a NULL value on @smem in
> > qcom_glink_smem_unregister().  This is a problem that should be fixed in the
> > driver rather than the core.
> > 
> > [1]. 
> > https://elixir.bootlin.com/linux/v6.12-rc4/source/drivers/remoteproc/qcom_common.c#L213
> 
> 
> I did the same here [1] but after discussion with Bjorn, realized that
> remoteproc might not even recover and may fail in the second attempt as
> well and only way is reboot of the machine.

Whether in RPROC_CRASHED or RPROC_DEFUNCT state, the end result is the same -
manual intervention is needed.  I don't see why another state needs to be added.

> 
> [1]
> https://lore.kernel.org/lkml/20240925103351.1628788-1-quic_mo...@quicinc.com/
> 
> > 
> > > Unable to handle kernel 
> > > NULL pointer dereference
> > > at 
> > > virtual address 0358
> > > 
> > > Signed-off-by: Mukesh Ojha 
> > > ---
> > > Changes in v3:
> > >  - Fix kernel test reported error.
> > > 
> > > Changes in v2:
> > >  - Removed NULL pointer check instead added a new state to signify
> > >non-recoverable state of remoteproc.
> > > 
> > >  drivers/remoteproc/remoteproc_core.c  | 3 ++-
> > >  drivers/remoteproc/remoteproc_sysfs.c | 1 +
> > >  include/linux/remoteproc.h

Re: [PATCH 1/4] dt-bindings: remoteproc: fsl,imx-rproc: add new compatible

[Mathieu Poirier]

Good day,

On Wed, Oct 23, 2024 at 12:21:11PM -0400, Laurentiu Mihalcea wrote:
> From: Laurentiu Mihalcea 
> 
> Add new compatible for imx95's CM7 with SOF.
> 
> Signed-off-by: Laurentiu Mihalcea 
> ---
>  .../bindings/remoteproc/fsl,imx-rproc.yaml| 58 +--
>  1 file changed, 53 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml 
> b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> index 57d75acb0b5e..ab0d8e017965 100644
> --- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> @@ -28,6 +28,15 @@ properties:
>- fsl,imx8qxp-cm4
>- fsl,imx8ulp-cm33
>- fsl,imx93-cm33
> +  - fsl,imx95-cm7-sof

Why is this added in the remoteproc bindings when the driver is
sound/soc/sof/imx/imx95.c?

> +
> +  reg:
> +maxItems: 2
> +
> +  reg-names:
> +items:
> +  - const: dram
> +  - const: mailbox
>  
>clocks:
>  maxItems: 1
> @@ -38,10 +47,8 @@ properties:
>Phandle to syscon block which provide access to System Reset Controller
>  
>mbox-names:
> -items:
> -  - const: tx
> -  - const: rx
> -  - const: rxdb
> +minItems: 1
> +maxItems: 4
>  
>mboxes:
>  description:
> @@ -49,7 +56,7 @@ properties:
>List of <&phandle type channel> - 1 channel for TX, 1 channel for RX, 
> 1 channel for RXDB.
>(see mailbox/fsl,mu.yaml)
>  minItems: 1
> -maxItems: 3
> +maxItems: 4
>  
>memory-region:
>  description:
> @@ -84,6 +91,10 @@ properties:
>This property is to specify the resource id of the remote processor in 
> SoC
>which supports SCFW
>  
> +  port:
> +$ref: /schemas/sound/audio-graph-port.yaml#
> +unevaluatedProperties: false
> +
>  required:
>- compatible
>  
> @@ -114,6 +125,43 @@ allOf:
>properties:
>  power-domains: false
>  
> +  - if:
> +  properties:
> +compatible:
> +  contains:
> +const: fsl,imx95-cm7-sof
> +then:
> +  properties:
> +mboxes:
> +  minItems: 4
> +mbox-names:
> +  items:
> +- const: txdb0
> +- const: txdb1
> +- const: rxdb0
> +- const: rxdb1
> +memory-region:
> +  maxItems: 1
> +  required:
> +- reg
> +- reg-names
> +- mboxes
> +- mbox-names
> +- memory-region
> +- port
> +else:
> +  properties:
> +reg: false
> +reg-names: false
> +mboxes:
> +  maxItems: 3
> +mbox-names:
> +  items:
> +- const: tx
> +- const: rx
> +- const: rxdb
> +port: false
> +
>  additionalProperties: false
>  
>  examples:
> -- 
> 2.34.1
> 

Re: [RFC PATCH] remoteproc: core: Add support for predefined notifyids

[Mathieu Poirier]

Hello Daniel,

On Fri, Oct 18, 2024 at 02:09:29PM +0300, Daniel Baluta wrote:
> Currently we generate notifyids in the linux kernel and override
> those found in rsc_table.
> 
> This doesn't play well with users expecting to use the exact ids
> from rsc_table.
> 
> So, use predefined notifyids found in rsc_table if any. Otherwise,
> let Linux generate the ids as before.
> 
> Keypoint is we also define an invalid notifid as 0xU. This
> should be placed as notifids if users want Linux to generate the ids.
> 
> Signed-off-by: Alexandru Lastur 
> Signed-off-by: Daniel Baluta 
> ---
>  drivers/remoteproc/remoteproc_core.c | 14 --
>  include/linux/remoteproc.h   |  1 +
>  2 files changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/remoteproc/remoteproc_core.c 
> b/drivers/remoteproc/remoteproc_core.c
> index f276956f2c5c..9f00fe16da38 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -332,6 +332,7 @@ int rproc_alloc_vring(struct rproc_vdev *rvdev, int i)
>   int ret, notifyid;
>   struct rproc_mem_entry *mem;
>   size_t size;
> + int start, end;
>  
>   /* actual size of vring (in bytes) */
>   size = PAGE_ALIGN(vring_size(rvring->num, rvring->align));
> @@ -363,9 +364,18 @@ int rproc_alloc_vring(struct rproc_vdev *rvdev, int i)
>   /*
>* Assign an rproc-wide unique index for this vring
>* TODO: assign a notifyid for rvdev updates as well
> -  * TODO: support predefined notifyids (via resource table)
>*/
> - ret = idr_alloc(&rproc->notifyids, rvring, 0, 0, GFP_KERNEL);
> +
> + start = 0;
> + end = 0;
> +
> + /* use id if specified in rsc table */
> + if (rsc->vring[i].notifyid != RSC_INVALID_NOTIFYID) {
> + start = rsc->vring[i].notifyid;
> + end = start + 1;
> + }

This will likely introduce a backward compatibility issue where anyone that
has more than one vring and set their notifyids to anything else than 0x
in the resource table will see a boot failure.

A while back the openAMP group started discussions on using the configuration
space of a virtio device to enhance device discovery, with exactly this kind of
use case in mind.  I think it is the only way to move forward with this
feature, though it is a big job that requires a lot of community interactions.

Regards,
Mathieu

> +
> + ret = idr_alloc(&rproc->notifyids, rvring, start, end, GFP_KERNEL);
>   if (ret < 0) {
>   dev_err(dev, "idr_alloc failed: %d\n", ret);
>   return ret;
> diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
> index b4795698d8c2..98c3e181086e 100644
> --- a/include/linux/remoteproc.h
> +++ b/include/linux/remoteproc.h
> @@ -238,6 +238,7 @@ struct fw_rsc_trace {
>   u8 name[32];
>  } __packed;
>  
> +#define RSC_INVALID_NOTIFYID 0xU
>  /**
>   * struct fw_rsc_vdev_vring - vring descriptor entry
>   * @da: device address
> -- 
> 2.43.0
> 

Re: [PATCH v11 7/7] remoteproc: stm32: Add support of an OP-TEE TA to load the firmware

[Mathieu Poirier]

On Wed, Oct 09, 2024 at 10:01:08AM +0200, Arnaud Pouliquen wrote:
> The new TEE remoteproc driver is used to manage remote firmware in a
> secure, trusted context. The 'st,stm32mp1-m4-tee' compatibility is
> introduced to delegate the loading of the firmware to the trusted
> execution context. In such cases, the firmware should be signed and
> adhere to the image format defined by the TEE.
> 
> Signed-off-by: Arnaud Pouliquen 
> ---
> updates vs v9 revision:
> - rename tee_interface to tee_rproc_itf
> - in stm32_rproc_probe(), test and use rproc->tee_rproc_itf instead of
>   trproc in the tee_rproc_unregister() call
> - initialize release_fw ops
> ---
>  drivers/remoteproc/stm32_rproc.c | 63 ++--
>  1 file changed, 60 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/remoteproc/stm32_rproc.c 
> b/drivers/remoteproc/stm32_rproc.c
> index 288bd70c7861..cb7093de41df 100644
> --- a/drivers/remoteproc/stm32_rproc.c
> +++ b/drivers/remoteproc/stm32_rproc.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -255,6 +256,19 @@ static int stm32_rproc_release(struct rproc *rproc)
>   return 0;
>  }
>  
> +static int stm32_rproc_tee_stop(struct rproc *rproc)
> +{
> + int err;
> +
> + stm32_rproc_request_shutdown(rproc);
> +
> + err = tee_rproc_stop(rproc);
> + if (err)
> + return err;
> +
> + return stm32_rproc_release(rproc);
> +}
> +
>  static int stm32_rproc_prepare(struct rproc *rproc)
>  {
>   struct device *dev = rproc->dev.parent;
> @@ -691,8 +705,20 @@ static const struct rproc_ops st_rproc_ops = {
>   .get_boot_addr  = rproc_elf_get_boot_addr,
>  };
>  
> +static const struct rproc_ops st_rproc_tee_ops = {
> + .prepare= stm32_rproc_prepare,
> + .start  = tee_rproc_start,
> + .stop   = stm32_rproc_tee_stop,
> + .kick   = stm32_rproc_kick,
> + .load   = tee_rproc_load_fw,
> + .parse_fw   = tee_rproc_parse_fw,
> + .find_loaded_rsc_table = tee_rproc_find_loaded_rsc_table,
> + .release_fw = tee_rproc_release_fw,
> +};
> +
>  static const struct of_device_id stm32_rproc_match[] = {
>   { .compatible = "st,stm32mp1-m4" },
> + { .compatible = "st,stm32mp1-m4-tee" },
>   {},
>  };
>  MODULE_DEVICE_TABLE(of, stm32_rproc_match);
> @@ -851,17 +877,42 @@ static int stm32_rproc_probe(struct platform_device 
> *pdev)
>   struct device *dev = &pdev->dev;
>   struct stm32_rproc *ddata;
>   struct device_node *np = dev->of_node;
> + struct tee_rproc *trproc = NULL;

The cleaner this patchset get, the more obvious it is (at least to me) that
struct tee_rproc needs to be changed to struct rproc_tee.  Otherwise I keep
wondering if this is coming from the TEE subsystem or the remoteproc subsystem.

>   struct rproc *rproc;
>   unsigned int state;
> + u32 proc_id;
>   int ret;
>  
>   ret = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(32));
>   if (ret)
>   return ret;
>  
> - rproc = devm_rproc_alloc(dev, np->name, &st_rproc_ops, NULL, 
> sizeof(*ddata));
> - if (!rproc)
> - return -ENOMEM;
> + if (of_device_is_compatible(np, "st,stm32mp1-m4-tee")) {
> + /*
> +  * Delegate the firmware management to the secure context.
> +  * The firmware loaded has to be signed.
> +  */
> + ret = of_property_read_u32(np, "st,proc-id", &proc_id);
> + if (ret) {
> + dev_err(dev, "failed to read st,rproc-id property\n");
> + return ret;
> + }
> +
> + rproc = devm_rproc_alloc(dev, np->name, &st_rproc_tee_ops, 
> NULL, sizeof(*ddata));
> + if (!rproc)
> + return -ENOMEM;
> +
> + trproc = tee_rproc_register(dev, rproc, proc_id);

This should return an integer rather than a struct tee_rproc * since the latter
is available through rproc->tee_rproc_itf.

In line with my comment above, this should be changed to rproc_tee_register()
since it belongs to the remoteproc subsystem.  Before when I asked for
tee_remoteproc.c to be changed to remoteproc_tee.c, I thought we could get by
without changing the inside but now I think it is clear that we can't - this
needs to be addressed.  

> + if (IS_ERR(trproc)) {
> + dev_err_probe(dev, PTR_ERR(trproc),
> +   "signed firmware not supported by TEE\n");
> + return PTR_ERR(trproc);

return dev_err_probe(...);
> + }
> + } else {
> + rproc = devm_rproc_alloc(dev, np->name, &st_rproc_ops, NULL, 
> sizeof(*ddata));
> + if (!rproc)
> + return -ENOMEM;
> + }
>  
>   ddata = rproc->priv;
>  
> @@ -913,6 +964,9 @@ static int stm32_rproc_probe(struct platform_device *pdev

Re: [PATCH v11 4/7] remoteproc: Introduce release_fw optional operation

[Mathieu Poirier]

On Wed, Oct 09, 2024 at 10:01:05AM +0200, Arnaud Pouliquen wrote:
> This patch updates the rproc_ops struct to include an optional
> release_fw function.
> 
> The release_fw ops is responsible for releasing the remote processor
> firmware image. The ops is called in the following cases:
> 
>  - An error occurs in rproc_start() between the loading of the segments and
>   the start of the remote processor.
>  - after stopping the remote processor.
> 
> Signed-off-by: Arnaud Pouliquen 
> ---
> Update vs v9 revision:
> - New commit that preplace previous one to introduce ops->release_fw
> ---
>  drivers/remoteproc/remoteproc_core.c | 5 +
>  include/linux/remoteproc.h   | 3 +++
>  2 files changed, 8 insertions(+)
> 
> diff --git a/drivers/remoteproc/remoteproc_core.c 
> b/drivers/remoteproc/remoteproc_core.c
> index 7694817f25d4..46863e1ca307 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -1258,6 +1258,9 @@ static int rproc_alloc_registered_carveouts(struct 
> rproc *rproc)
>  
>  static void rproc_release_fw(struct rproc *rproc)
>  {
> + if (rproc->ops->release_fw)
> + rproc->ops->release_fw(rproc);
> +
>   /* Free the copy of the resource table */
>   kfree(rproc->cached_table);
>   rproc->cached_table = NULL;
> @@ -1377,6 +1380,8 @@ static int rproc_start(struct rproc *rproc, const 
> struct firmware *fw)
>  unprepare_subdevices:
>   rproc_unprepare_subdevices(rproc);
>  reset_table_ptr:
> + if (rproc->ops->release_fw)
> + rproc->ops->release_fw(rproc);
>   rproc->table_ptr = rproc->cached_table;
>  
>   return ret;
> diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
> index 73f640dd0fc0..bdf4d94a9e63 100644
> --- a/include/linux/remoteproc.h
> +++ b/include/linux/remoteproc.h
> @@ -381,6 +381,8 @@ enum rsc_handling_status {
>   * @panic:   optional callback to react to system panic, core will delay
>   *   panic at least the returned number of milliseconds
>   * @coredump:  collect firmware dump after the subsystem is shutdown
> + * @release_fw:  optional function to release the firmware image from 
> ROM memories.
> + *  This function is called after stopping the process or in 
> case of an error

... after stopping the process?

>   */
>  struct rproc_ops {
>   int (*prepare)(struct rproc *rproc);
> @@ -403,6 +405,7 @@ struct rproc_ops {
>   u64 (*get_boot_addr)(struct rproc *rproc, const struct firmware *fw);
>   unsigned long (*panic)(struct rproc *rproc);
>   void (*coredump)(struct rproc *rproc);
> + void (*release_fw)(struct rproc *rproc);
>  };
>  
>  /**
> -- 
> 2.25.1
> 

Re: [PATCH v11 2/7] remoteproc: Add TEE support

[Mathieu Poirier]

On Wed, Oct 09, 2024 at 10:01:03AM +0200, Arnaud Pouliquen wrote:
> Add a remoteproc TEE (Trusted Execution Environment) driver
> that will be probed by the TEE bus. If the associated Trusted
> application is supported on secure part this driver offers a client
> interface to load a firmware by the secure part.
> This firmware could be authenticated by the secure trusted application.
> 
> Signed-off-by: Arnaud Pouliquen 
> ---
> Updates vs v9 revision:
> - remove unused trproc variable in tee_rproc_find_loaded_rsc_table(),
> - add check on trproc in tee_rproc_get_loaded_rsc_table()
> - move REMOTEPROC_TEE declaration just after REMOTEPROC_CDEV in Makefile
>   and Kconfig files
> - rename MAX_TEE_PARAM_ARRY_MEMBER to MAX_TEE_PARAM_ARRAY_MEMBER
> - rename tee_interface to rproc_tee_itf to better identify that it is
>   related to the remoteproc tee implementation,not to a platform
>   implementation such as Qualcomm.
> - print an error in tee_rproc_release_fw() instead of returning the error
>   No action can be done to fix get out from the release error.
> ---
>  drivers/remoteproc/Kconfig  |  10 +
>  drivers/remoteproc/Makefile |   1 +
>  drivers/remoteproc/remoteproc_tee.c | 506 
>  include/linux/remoteproc.h  |   4 +
>  include/linux/remoteproc_tee.h  | 107 ++
>  5 files changed, 628 insertions(+)
>  create mode 100644 drivers/remoteproc/remoteproc_tee.c
>  create mode 100644 include/linux/remoteproc_tee.h
> 
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index 955e4e38477e..d0284220a194 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -23,6 +23,16 @@ config REMOTEPROC_CDEV
>  
> It's safe to say N if you don't want to use this interface.
>  
> +config REMOTEPROC_TEE
> + tristate "Remoteproc support by a TEE application"
> + depends on OPTEE
> + help
> +   Support a remote processor with a TEE application. The Trusted
> +   Execution Context is responsible for loading the trusted firmware
> +   image and managing the remote processor's lifecycle.
> +
> +   It's safe to say N if you don't want to use remoteproc TEE.
> +
>  config IMX_REMOTEPROC
>   tristate "i.MX remoteproc support"
>   depends on ARCH_MXC
> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> index 5ff4e2fee4ab..f77e0abe8349 100644
> --- a/drivers/remoteproc/Makefile
> +++ b/drivers/remoteproc/Makefile
> @@ -11,6 +11,7 @@ remoteproc-y+= 
> remoteproc_sysfs.o
>  remoteproc-y += remoteproc_virtio.o
>  remoteproc-y += remoteproc_elf_loader.o
>  obj-$(CONFIG_REMOTEPROC_CDEV)+= remoteproc_cdev.o
> +obj-$(CONFIG_REMOTEPROC_TEE) += remoteproc_tee.o
>  obj-$(CONFIG_IMX_REMOTEPROC) += imx_rproc.o
>  obj-$(CONFIG_IMX_DSP_REMOTEPROC) += imx_dsp_rproc.o
>  obj-$(CONFIG_INGENIC_VPU_RPROC)  += ingenic_rproc.o
> diff --git a/drivers/remoteproc/remoteproc_tee.c 
> b/drivers/remoteproc/remoteproc_tee.c
> new file mode 100644
> index ..74d826792da8
> --- /dev/null
> +++ b/drivers/remoteproc/remoteproc_tee.c
> @@ -0,0 +1,506 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) STMicroelectronics 2024
> + * Author: Arnaud Pouliquen 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define MAX_TEE_PARAM_ARRAY_MEMBER   4
> +
> +/*
> + * Authentication of the firmware and load in the remote processor memory
> + *
> + * [in]  params[0].value.a:  unique 32bit identifier of the remote processor
> + * [in]   params[1].memref:  buffer containing the image of the 
> buffer
> + */
> +#define TA_RPROC_FW_CMD_LOAD_FW  1
> +
> +/*
> + * Start the remote processor
> + *
> + * [in]  params[0].value.a:  unique 32bit identifier of the remote processor
> + */
> +#define TA_RPROC_FW_CMD_START_FW 2
> +
> +/*
> + * Stop the remote processor
> + *
> + * [in]  params[0].value.a:  unique 32bit identifier of the remote processor
> + */
> +#define TA_RPROC_FW_CMD_STOP_FW  3
> +
> +/*
> + * Return the address of the resource table, or 0 if not found
> + * No check is done to verify that the address returned is accessible by
> + * the non secure context. If the resource table is loaded in a protected
> + * memory the access by the non secure context will lead to a data abort.
> + *
> + * [in]  params[0].value.a:  unique 32bit identifier of the remote processor
> + * [out]  params[1].value.a: 32bit LSB resource table memory address
> + * [out]  params[1].value.b: 32bit MSB resource table memory address
> + * [out]  params[2].value.a: 32bit LSB resource table memory size
> + * [out]  params[2].value.b: 32bit MSB resource table memory size
> + */
> +#define TA_RPROC_FW_CMD_GET_RSC_TABLE4
> +
> +/*
> + * Return the address of the core dump
> + *

Re: [PATCH v3] remoteproc: Add a new remoteproc state RPROC_DEFUNCT

[Mathieu Poirier]

Hi Mukesh,

On Wed, Oct 16, 2024 at 10:25:46AM +0530, Mukesh Ojha wrote:
> Multiple call to glink_subdev_stop() for the same remoteproc can happen
> if rproc_stop() fails from Process-A that leaves the rproc state to
> RPROC_CRASHED state later a call to recovery_store from user space in
> Process B triggers rproc_trigger_recovery() of the same remoteproc to
> recover it results in NULL pointer dereference issue in
> qcom_glink_smem_unregister().
> 
> There is other side to this issue if we want to fix this via adding a
> NULL check on glink->edge which does not guarantees that the remoteproc
> will recover in second call from Process B as it has failed in the first
> Process A during SMC shutdown call and may again fail at the same call
> and rproc can not recover for such case.
> 
> Add a new rproc state RPROC_DEFUNCT i.e., non recoverable state of
> remoteproc and the only way to recover from it via system restart.
> 
>   Process-A   Process-B
> 
>   fatal error interrupt happens
> 
>   rproc_crash_handler_work()
> mutex_lock_interruptible(&rproc->lock);
> ...
> 
>rproc->state = RPROC_CRASHED;
> ...
> mutex_unlock(&rproc->lock);
> 
> rproc_trigger_recovery()
>  mutex_lock_interruptible(&rproc->lock);
> 
>   adsp_stop()
>   qcom_q6v5_pas 20c0.remoteproc: failed to shutdown: -22
>   remoteproc remoteproc3: can't stop rproc: -22
>  mutex_unlock(&rproc->lock);

Ok, that can happen.

> 
>   echo enabled > 
> /sys/class/remoteproc/remoteprocX/recovery
>   recovery_store()
>rproc_trigger_recovery()
> 
> mutex_lock_interruptible(&rproc->lock);
>  rproc_stop()
>   glink_subdev_stop()
> 
> qcom_glink_smem_unregister() ==|
>   
>|
>   
>V

I am missing some information here but I will _assume_ this is caused by
glink->edge being set to NULL [1] when glink_subdev_stop() is first called by
process A.  Instead of adding a new state to the core I think a better idea
would be to add a check for a NULL value on @smem in
qcom_glink_smem_unregister().  This is a problem that should be fixed in the
driver rather than the core.

[1]. 
https://elixir.bootlin.com/linux/v6.12-rc4/source/drivers/remoteproc/qcom_common.c#L213

> Unable to handle kernel 
> NULL pointer dereference
> at virtual 
> address 0358
> 
> Signed-off-by: Mukesh Ojha 
> ---
> Changes in v3:
>  - Fix kernel test reported error.
> 
> Changes in v2:
>  - Removed NULL pointer check instead added a new state to signify
>non-recoverable state of remoteproc.
> 
>  drivers/remoteproc/remoteproc_core.c  | 3 ++-
>  drivers/remoteproc/remoteproc_sysfs.c | 1 +
>  include/linux/remoteproc.h| 5 -
>  3 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/remoteproc/remoteproc_core.c 
> b/drivers/remoteproc/remoteproc_core.c
> index f276956f2c5c..c4e14503b971 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -1727,6 +1727,7 @@ static int rproc_stop(struct rproc *rproc, bool crashed)
>   /* power off the remote processor */
>   ret = rproc->ops->stop(rproc);
>   if (ret) {
> + rproc->state = RPROC_DEFUNCT;
>   dev_err(dev, "can't stop rproc: %d\n", ret);
>   return ret;
>   }
> @@ -1839,7 +1840,7 @@ int rproc_trigger_recovery(struct rproc *rproc)
>   return ret;
>  
>   /* State could have changed before we got the mutex */
> - if (rproc->state != RPROC_CRASHED)
> + if (rproc->state == RPROC_DEFUNCT || rproc->state != RPROC_CRASHED)
>   goto unlock_mutex;

The problem is that rproc_trigger_recovery() an only be called once for a
remoteproc, something that modifies the state machine and may introduce backward
compatibility issues for other remote processor implementations.

Thanks,
Mathieu

>  
>   dev_err(dev, "recovering %s\n", rproc->name);
> diff --git a/drivers/remoteproc/remoteproc_sysfs.c 
> b/drivers/remoteproc/remoteproc_sysfs.c
> index 138e752c5e4e..5f722b4576b2 100644
> --- a/drivers/remoteproc/remoteproc_sysfs.c
> +++ b/drivers/remoteproc/remoteproc_sysfs.c
> @@ -171,6 +171,7 @@ static const char * const rproc_state_string[] = {
>   [RPROC_DELETED] = "deleted",
>   [RPROC_ATTACHED]= "attached",
>   [RPROC_DETACHED]= "detached",
> + [RPR

Re: [PATCH 0/2] Enable compile testing for K3 RemoteProc drivers

[Mathieu Poirier]

On Wed, Oct 16, 2024 at 11:41:39AM -0500, Andrew Davis wrote:
> Hello all,
> 
> This is a follow up to [0] that adds the same for the other two K3
> RemoteProc drivers. Series is based on rproc-next branch.
> 
> Thanks,
> Andrew
> 
> [0] https://lore.kernel.org/lkml/20241007132441.2732215-1-a...@kernel.org/
> 
> Andrew Davis (2):
>   remoteproc: k3-dsp: Add compile testing support
>   remoteproc: k3-r5: Add compile testing support
>

I have applied this set.

Thanks,
Mathieu

>  drivers/remoteproc/Kconfig | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> -- 
> 2.39.2
> 

Re: [PATCH] mailbox, remoteproc: k3-m4+: fix compile testing

[Mathieu Poirier]

On Wed, Oct 16, 2024 at 10:37:35AM -0500, Andrew Davis wrote:
> On 10/16/24 10:26 AM, Mathieu Poirier wrote:
> > On Mon, Oct 14, 2024 at 09:56:11AM -0500, Andrew Davis wrote:
> > > On 10/7/24 8:23 AM, Arnd Bergmann wrote:
> > > > From: Arnd Bergmann 
> > > > 
> > > > The k3-m4 remoteproc driver was merged with incorrect dependencies.
> > > > Despite multiple people trying to fix this, the version 6.12-rc2
> > > > remains broken and causes a build failure with CONFIG_TI_SCI_PROTOCOL=m
> > > > when the driver is built-in.
> > > > 
> > > > arm-linux-gnueabi-ld: drivers/remoteproc/ti_k3_m4_remoteproc.o: in 
> > > > function `k3_m4_rproc_probe':
> > > > ti_k3_m4_remoteproc.c:(.text.k3_m4_rproc_probe+0x76): undefined 
> > > > reference to `devm_ti_sci_get_by_phandle'
> > > > 
> > > > Fix the dependency again to make it work in all configurations.
> > > > The 'select OMAP2PLUS_MBOX' no longer matches what the other drivers
> > > > dependencies. The link failure can be avoided with a simple 'depends
> > > > do, so turn that into the same 'depends' to ensure we get no circular
> > > > on TI_SCI_PROTOCOL', but the extra COMPILE_TEST alternative is what
> > > > we use elsehwere. On the other hand, building for OMAP2PLUS makes
> > > > no sense since the hardware only exists on K3.
> > > > 
> > > > Fixes: ebcf9008a895 ("remoteproc: k3-m4: Add a remoteproc driver for 
> > > > M4F subsystem")
> > > > Fixes: ba0c0cb56f22 ("remoteproc: k3-m4: use the proper dependencies")
> > > > Fixes: 54595f2807d2 ("mailbox, remoteproc: omap2+: fix compile testing")
> > > > Signed-off-by: Arnd Bergmann 
> > > > ---
> > > >drivers/remoteproc/Kconfig | 6 +++---
> > > >1 file changed, 3 insertions(+), 3 deletions(-)
> > > > 
> > > > diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> > > > index 955e4e38477e..62f8548fb46a 100644
> > > > --- a/drivers/remoteproc/Kconfig
> > > > +++ b/drivers/remoteproc/Kconfig
> > > > @@ -341,9 +341,9 @@ config TI_K3_DSP_REMOTEPROC
> > > >config TI_K3_M4_REMOTEPROC
> > > > tristate "TI K3 M4 remoteproc support"
> > > > -   depends on ARCH_OMAP2PLUS || ARCH_K3
> > > > -   select MAILBOX
> > > > -   select OMAP2PLUS_MBOX
> > > > +   depends on ARCH_K3 || COMPILE_TEST
> > > > +   depends on TI_SCI_PROTOCOL || (COMPILE_TEST && 
> > > > TI_SCI_PROTOCOL=n)
> > > 
> > > This line is odd. IMHO "COMPILE_TEST" should only be added to ARCH_*
> > > dependencies, as often only one ARCH can be selected which prevents
> > > compile testing drivers with various multiple architecture deps in
> > > one compile test.
> > > 
> > > Normal dependencies, on the other hand, can simply be enabled if one
> > > wants to compile test its dependent drivers. In this case, TI_SCI_PROTOCOL
> > > cannot be enabled as it has a dependency up the chain that doesn't
> > > allow selecting when not on a TI platform. We can fix that as I posted
> > > here[0]. With that fix in, this line can be simply become:
> > > 
> > > depends on TI_SCI_PROTOCOL
> > 
> >  From the above and the follow-on conversation with Nishanth, should I 
> > understand
> > you are working on a patchset to address this issue?  If not I will apply 
> > Arnd's
> > patch.  People are sending different fix [1] - the issue needs to be 
> > addressed
> > well before the end of the cycle.
> > 
> 
> This is a bit complex as it touches multiple subsystems. You should take 
> Arnd's
> patch. This will fix this for M4, I will then add a follow on patch doing the 
> same
> for the other two remoteproc drivers (DSP and R5).
> 
> When my series here[0] goes in I will then send a final patch removing the 
> depends
> TI_SCI_PROTOCOL=n oddness from all 3 drivers. This final step does not need 
> to happen
> this cycle though, only the first two steps are needed to prevent any further 
> compile
> test issues.
>

I have applied Arnd's patch.

> Andrew
> 
> [0] https://lore.kernel.org/lkml/20241015213322.2649011-1-...@ti.com/
> 
> > [1]. 
> > https://lore.kernel.org/linux-arm-kernel/20241016013922.1392290-1-zenghe...@huawei.com/T/
> > 
> > > 
> > > Andrew
> > > 
> > > [0] https://lore.kernel.org/lkml/20241014144821.15094-1-...@ti.com/
> > > 
> > > > +   depends on OMAP2PLUS_MBOX
> > > > help
> > > >   Say m here to support TI's M4 remote processor subsystems
> > > >   on various TI K3 family of SoCs through the remote processor

Re: [PATCH] mailbox, remoteproc: k3-m4+: fix compile testing

[Mathieu Poirier]

On Mon, Oct 14, 2024 at 09:56:11AM -0500, Andrew Davis wrote:
> On 10/7/24 8:23 AM, Arnd Bergmann wrote:
> > From: Arnd Bergmann 
> > 
> > The k3-m4 remoteproc driver was merged with incorrect dependencies.
> > Despite multiple people trying to fix this, the version 6.12-rc2
> > remains broken and causes a build failure with CONFIG_TI_SCI_PROTOCOL=m
> > when the driver is built-in.
> > 
> > arm-linux-gnueabi-ld: drivers/remoteproc/ti_k3_m4_remoteproc.o: in function 
> > `k3_m4_rproc_probe':
> > ti_k3_m4_remoteproc.c:(.text.k3_m4_rproc_probe+0x76): undefined reference 
> > to `devm_ti_sci_get_by_phandle'
> > 
> > Fix the dependency again to make it work in all configurations.
> > The 'select OMAP2PLUS_MBOX' no longer matches what the other drivers
> > dependencies. The link failure can be avoided with a simple 'depends
> > do, so turn that into the same 'depends' to ensure we get no circular
> > on TI_SCI_PROTOCOL', but the extra COMPILE_TEST alternative is what
> > we use elsehwere. On the other hand, building for OMAP2PLUS makes
> > no sense since the hardware only exists on K3.
> > 
> > Fixes: ebcf9008a895 ("remoteproc: k3-m4: Add a remoteproc driver for M4F 
> > subsystem")
> > Fixes: ba0c0cb56f22 ("remoteproc: k3-m4: use the proper dependencies")
> > Fixes: 54595f2807d2 ("mailbox, remoteproc: omap2+: fix compile testing")
> > Signed-off-by: Arnd Bergmann 
> > ---
> >   drivers/remoteproc/Kconfig | 6 +++---
> >   1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> > index 955e4e38477e..62f8548fb46a 100644
> > --- a/drivers/remoteproc/Kconfig
> > +++ b/drivers/remoteproc/Kconfig
> > @@ -341,9 +341,9 @@ config TI_K3_DSP_REMOTEPROC
> >   config TI_K3_M4_REMOTEPROC
> > tristate "TI K3 M4 remoteproc support"
> > -   depends on ARCH_OMAP2PLUS || ARCH_K3
> > -   select MAILBOX
> > -   select OMAP2PLUS_MBOX
> > +   depends on ARCH_K3 || COMPILE_TEST
> > +   depends on TI_SCI_PROTOCOL || (COMPILE_TEST && TI_SCI_PROTOCOL=n)
> 
> This line is odd. IMHO "COMPILE_TEST" should only be added to ARCH_*
> dependencies, as often only one ARCH can be selected which prevents
> compile testing drivers with various multiple architecture deps in
> one compile test.
> 
> Normal dependencies, on the other hand, can simply be enabled if one
> wants to compile test its dependent drivers. In this case, TI_SCI_PROTOCOL
> cannot be enabled as it has a dependency up the chain that doesn't
> allow selecting when not on a TI platform. We can fix that as I posted
> here[0]. With that fix in, this line can be simply become:
> 
> depends on TI_SCI_PROTOCOL

>From the above and the follow-on conversation with Nishanth, should I 
>understand
you are working on a patchset to address this issue?  If not I will apply Arnd's
patch.  People are sending different fix [1] - the issue needs to be addressed
well before the end of the cycle.

[1]. 
https://lore.kernel.org/linux-arm-kernel/20241016013922.1392290-1-zenghe...@huawei.com/T/

> 
> Andrew
> 
> [0] https://lore.kernel.org/lkml/20241014144821.15094-1-...@ti.com/
> 
> > +   depends on OMAP2PLUS_MBOX
> > help
> >   Say m here to support TI's M4 remote processor subsystems
> >   on various TI K3 family of SoCs through the remote processor

Re: [PATCH] rpmsg_ns: Work around TI non-standard message

[Mathieu Poirier]

On Tue, Oct 15, 2024 at 06:58:33PM +0200, Richard Weinberger wrote:
> Mathieu,
> 
> Am Dienstag, 15. Oktober 2024, 18:48:08 CEST schrieb Mathieu Poirier:
> > Good morning Richard,
> > 
> > On Fri, Oct 11, 2024 at 02:39:22PM +0200, Richard Weinberger wrote:
> > > Texas Instruments ships a patch in their vendor kernels,
> > > which adds a new NS message that includes a description field.
> > > While TI is free to do whatever they want in their copy of the kernel,
> > > it becomes a mess when people switch to a mainline kernel and want
> > > to use their existing DSP programs with it.
> > 
> > I suspect there is a lot more things to change when going from downstream 
> > to a
> > mainline kernel.
> 
> Not really.
> I had to revert c6aed238b7a9b ("remoteproc: modify vring allocation to rely 
> on centralized carveout allocator")
> because the DSP has a sub-optimal resource table, and this workaround.
> With that the DSP program worked as-is on kernel 6.6.
> Downstream was 4.19 TI.
> 
> > > 
> > > To make it easier to migrate to a mainline kernel,
> > > let's make the kernel aware of their non-standard extension but
> > > briefly ignore the description field.
> > 
> > In my opinion the real fix here is to get TI to use the standard message
> > announcement structure.  The ->desc field doesn't seem to be that useful 
> > since
> > it gets discarted.
> 
> This is for the future, the goal of my patch is helping people to
> get existing DSP programs work with mainline.
> Not everyone can or want to rebuild theirs DSP programs when moving to a 
> mainline
> kernel.

That's an even better argument to adopt the standard structure as soon as
possible.  Modifying the mainline kernel to adapt to vendors' quirks doesn't
scale.  

> 
> Thanks,
> //richard
> 
> -- 
> ​sigma star gmbh | Eduard-Bodem-Gasse 6, 6020 Innsbruck, AUT
> UID/VAT Nr: ATU 66964118 | FN: 374287y
> 
> 

Re: [PATCH 00/10] remoteproc: few dev_err_probe() and other cleanups/improvements

[Mathieu Poirier]

On Fri, Oct 11, 2024 at 03:09:08PM +0200, Krzysztof Kozlowski wrote:
> Simplify drivers in few places around probe function.
> 
> Best regards,
> Krzysztof
> 
> ---
> Krzysztof Kozlowski (10):
>   remoteproc: da8xx: Handle deferred probe
>   remoteproc: da8xx: Simplify with dev_err_probe()
>   remoteproc: ti_k3_r5: Simplify with dev_err_probe()
>   remoteproc: ti_k3_r5: Simplify with scoped for each OF child loop

I have applied patches 1 to 4.  I will let Bjorn do the QC ones.

Thanks,
Mathieu

>   remoteproc: qcom_q6v5_adsp: Simplify with dev_err_probe()
>   remoteproc: qcom_q6v5_mss: Simplify with dev_err_probe()
>   remoteproc: qcom_q6v5_mss: Drop redundant error printks in probe
>   remoteproc: qcom_q6v5_pas: Simplify with dev_err_probe()
>   remoteproc: qcom_q6v5_wcss: Simplify with dev_err_probe()
>   remoteproc: qcom_wcnss_iris: Simplify with dev_err_probe()
> 
>  drivers/remoteproc/da8xx_remoteproc.c| 29 +++---
>  drivers/remoteproc/qcom_q6v5_adsp.c  | 17 +++---
>  drivers/remoteproc/qcom_q6v5_mss.c   | 48 +
>  drivers/remoteproc/qcom_q6v5_pas.c   | 22 +++-
>  drivers/remoteproc/qcom_q6v5_wcss.c  | 92 
> +++-
>  drivers/remoteproc/qcom_wcnss_iris.c |  5 +-
>  drivers/remoteproc/ti_k3_r5_remoteproc.c | 74 +
>  7 files changed, 92 insertions(+), 195 deletions(-)
> ---
> base-commit: 0cca97bf23640ff68a6e8a74e9b6659fdc27f48c
> change-id: 20241011-remote-proc-dev-err-probe-c986de9e93de
> 
> Best regards,
> -- 
> Krzysztof Kozlowski 
> 

Re: [PATCH] rpmsg_ns: Work around TI non-standard message

[Mathieu Poirier]

Good morning Richard,

On Fri, Oct 11, 2024 at 02:39:22PM +0200, Richard Weinberger wrote:
> Texas Instruments ships a patch in their vendor kernels,
> which adds a new NS message that includes a description field.
> While TI is free to do whatever they want in their copy of the kernel,
> it becomes a mess when people switch to a mainline kernel and want
> to use their existing DSP programs with it.

I suspect there is a lot more things to change when going from downstream to a
mainline kernel.  

> 
> To make it easier to migrate to a mainline kernel,
> let's make the kernel aware of their non-standard extension but
> briefly ignore the description field.

In my opinion the real fix here is to get TI to use the standard message
announcement structure.  The ->desc field doesn't seem to be that useful since
it gets discarted.

Thanks,
Mathieu

> 
> [0] 
> https://patchwork.kernel.org/project/linux-remoteproc/patch/20190815231448.10100-1-s-a...@ti.com/
> [1] 
> https://stash.phytec.com/projects/PUB/repos/linux-phytec-ti/commits/aeded1f439effc84aa9f4e341a6e92ce1844ab98#drivers/rpmsg/virtio_rpmsg_bus.c
> 
> Cc: o...@wizery.com
> Cc: s-a...@ti.com
> Cc: t-kri...@ti.com
> Signed-off-by: Richard Weinberger 
> ---
> FWIW, this is a forward port of a patch I'm using on v6.6.
> 
> Thanks,
> //richard
> ---
>  drivers/rpmsg/rpmsg_ns.c | 30 ++
>  include/linux/rpmsg/ns.h |  8 
>  2 files changed, 30 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/rpmsg/rpmsg_ns.c b/drivers/rpmsg/rpmsg_ns.c
> index bde8c8d433e0a..2fb3721eb0141 100644
> --- a/drivers/rpmsg/rpmsg_ns.c
> +++ b/drivers/rpmsg/rpmsg_ns.c
> @@ -31,10 +31,11 @@ EXPORT_SYMBOL(rpmsg_ns_register_device);
>  static int rpmsg_ns_cb(struct rpmsg_device *rpdev, void *data, int len,
>  void *priv, u32 src)
>  {
> - struct rpmsg_ns_msg *msg = data;
>   struct rpmsg_device *newch;
>   struct rpmsg_channel_info chinfo;
>   struct device *dev = rpdev->dev.parent;
> + __rpmsg32 ns_addr, ns_flags;
> + char *ns_name;
>   int ret;
>  
>  #if defined(CONFIG_DYNAMIC_DEBUG)
> @@ -42,23 +43,36 @@ static int rpmsg_ns_cb(struct rpmsg_device *rpdev, void 
> *data, int len,
>data, len, true);
>  #endif
>  
> - if (len != sizeof(*msg)) {
> + if (len == sizeof(struct rpmsg_ns_msg)) {
> + struct rpmsg_ns_msg *msg = data;
> +
> + ns_addr = msg->addr;
> + ns_flags = msg->flags;
> + ns_name = msg->name;
> + } else if (len == sizeof(struct __rpmsg_ns_msg_ti)) {
> + struct __rpmsg_ns_msg_ti *msg = data;
> +
> + ns_addr = msg->addr;
> + ns_flags = msg->flags;
> + ns_name = msg->name;
> + dev_warn(dev, "non-standard ns msg found\n");
> + } else {
>   dev_err(dev, "malformed ns msg (%d)\n", len);
>   return -EINVAL;
>   }
>  
>   /* don't trust the remote processor for null terminating the name */
> - msg->name[RPMSG_NAME_SIZE - 1] = '\0';
> + ns_name[RPMSG_NAME_SIZE - 1] = '\0';
>  
> - strscpy_pad(chinfo.name, msg->name, sizeof(chinfo.name));
> + strscpy_pad(chinfo.name, ns_name, sizeof(chinfo.name));
>   chinfo.src = RPMSG_ADDR_ANY;
> - chinfo.dst = rpmsg32_to_cpu(rpdev, msg->addr);
> + chinfo.dst = rpmsg32_to_cpu(rpdev, ns_addr);
>  
>   dev_info(dev, "%sing channel %s addr 0x%x\n",
> -  rpmsg32_to_cpu(rpdev, msg->flags) & RPMSG_NS_DESTROY ?
> -  "destroy" : "creat", msg->name, chinfo.dst);
> +  rpmsg32_to_cpu(rpdev, ns_flags) & RPMSG_NS_DESTROY ?
> +  "destroy" : "creat", ns_name, chinfo.dst);
>  
> - if (rpmsg32_to_cpu(rpdev, msg->flags) & RPMSG_NS_DESTROY) {
> + if (rpmsg32_to_cpu(rpdev, ns_flags) & RPMSG_NS_DESTROY) {
>   ret = rpmsg_release_channel(rpdev, &chinfo);
>   if (ret)
>   dev_err(dev, "rpmsg_destroy_channel failed: %d\n", ret);
> diff --git a/include/linux/rpmsg/ns.h b/include/linux/rpmsg/ns.h
> index a7804edd6d58f..60fca84ad4cea 100644
> --- a/include/linux/rpmsg/ns.h
> +++ b/include/linux/rpmsg/ns.h
> @@ -26,6 +26,14 @@ struct rpmsg_ns_msg {
>   __rpmsg32 flags;
>  } __packed;
>  
> +/* Non-standard extended ns message by Texas Instruments */
> +struct __rpmsg_ns_msg_ti {
> + char name[RPMSG_NAME_SIZE];
> + char desc[RPMSG_NAME_SIZE]; /* ignored */
> + u32 addr;
> + u32 flags;
> +} __packed;
> +
>  /**
>   * enum rpmsg_ns_flags - dynamic name service announcement flags
>   *
> -- 
> 2.35.3
> 

Re: [PATCH] mailbox, remoteproc: k3-m4+: fix compile testing

[Mathieu Poirier]

Hi Arnd,

On Mon, Oct 07, 2024 at 01:23:57PM +, Arnd Bergmann wrote:
> From: Arnd Bergmann 
> 
> The k3-m4 remoteproc driver was merged with incorrect dependencies.
> Despite multiple people trying to fix this, the version 6.12-rc2
> remains broken and causes a build failure with CONFIG_TI_SCI_PROTOCOL=m
> when the driver is built-in.
> 
> arm-linux-gnueabi-ld: drivers/remoteproc/ti_k3_m4_remoteproc.o: in function 
> `k3_m4_rproc_probe':
> ti_k3_m4_remoteproc.c:(.text.k3_m4_rproc_probe+0x76): undefined reference to 
> `devm_ti_sci_get_by_phandle'
> 
> Fix the dependency again to make it work in all configurations.
> The 'select OMAP2PLUS_MBOX' no longer matches what the other drivers
> dependencies. The link failure can be avoided with a simple 'depends
> do, so turn that into the same 'depends' to ensure we get no circular
> on TI_SCI_PROTOCOL', but the extra COMPILE_TEST alternative is what
> we use elsehwere. On the other hand, building for OMAP2PLUS makes
> no sense since the hardware only exists on K3.
> 
> Fixes: ebcf9008a895 ("remoteproc: k3-m4: Add a remoteproc driver for M4F 
> subsystem")
> Fixes: ba0c0cb56f22 ("remoteproc: k3-m4: use the proper dependencies")
> Fixes: 54595f2807d2 ("mailbox, remoteproc: omap2+: fix compile testing")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/remoteproc/Kconfig | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index 955e4e38477e..62f8548fb46a 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -341,9 +341,9 @@ config TI_K3_DSP_REMOTEPROC
>  
>  config TI_K3_M4_REMOTEPROC
>   tristate "TI K3 M4 remoteproc support"
> - depends on ARCH_OMAP2PLUS || ARCH_K3
> - select MAILBOX
> - select OMAP2PLUS_MBOX
> + depends on ARCH_K3 || COMPILE_TEST
> + depends on TI_SCI_PROTOCOL || (COMPILE_TEST && TI_SCI_PROTOCOL=n)
> + depends on OMAP2PLUS_MBOX

I have tested this patch with CONFIG_TI_SCI_PROTOCOL=m on Arm and allmodconfig 
on
x86-64 - both compilation work.

I can apply this patch as is or you can send me another one with the
modifications you did for TI_K3_DSP_REMOTEPROC and TI_K3_R5_REMOTEPROC in your
previous [1] attempt to fix this.

Thanks,
Mathieu


[1]. https://lore.kernel.org/all/20240909203825.1666947-1-a...@kernel.org/
>   help
> Say m here to support TI's M4 remote processor subsystems
> on various TI K3 family of SoCs through the remote processor
> -- 
> 2.39.2
> 

Re: [PATCH v10 7/7] remoteproc: stm32: Add support of an OP-TEE TA to load the firmware

[Mathieu Poirier]

>From hereon and starting with this version, I will not review patchets that
don't pass the compilation bots.

Mathieu

On Tue, Oct 08, 2024 at 07:07:40PM +0800, kernel test robot wrote:
> Hi Arnaud,
> 
> kernel test robot noticed the following build warnings:
> 
> [auto build test WARNING on 9852d85ec9d492ebef56dc5f229416c925758edc]
> 
> url:
> https://github.com/intel-lab-lkp/linux/commits/Arnaud-Pouliquen/remoteproc-core-Introduce-rproc_pa_to_va-helper/20241007-212358
> base:   9852d85ec9d492ebef56dc5f229416c925758edc
> patch link:
> https://lore.kernel.org/r/20241007131620.2090104-8-arnaud.pouliquen%40foss.st.com
> patch subject: [PATCH v10 7/7] remoteproc: stm32: Add support of an OP-TEE TA 
> to load the firmware
> config: alpha-kismet-CONFIG_REMOTEPROC_TEE-CONFIG_STM32_RPROC-0-0 
> (https://download.01.org/0day-ci/archive/20241008/202410081902.twqcmwjk-...@intel.com/config)
> reproduce: 
> (https://download.01.org/0day-ci/archive/20241008/202410081902.twqcmwjk-...@intel.com/reproduce)
> 
> If you fix the issue in a separate patch/commit (i.e. not just a new version 
> of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot 
> | Closes: 
> https://lore.kernel.org/oe-kbuild-all/202410081902.twqcmwjk-...@intel.com/
> 
> kismet warnings: (new ones prefixed by >>)
> >> kismet: WARNING: unmet direct dependencies detected for REMOTEPROC_TEE 
> >> when selected by STM32_RPROC
>WARNING: unmet direct dependencies detected for REMOTEPROC_TEE
>  Depends on [n]: REMOTEPROC [=y] && OPTEE [=n]
>  Selected by [y]:
>  - STM32_RPROC [=y] && (ARCH_STM32 || COMPILE_TEST [=y]) && REMOTEPROC 
> [=y]
> 
> -- 
> 0-DAY CI Kernel Test Service
> https://github.com/intel/lkp-tests/wiki

Re: [PATCH] mailbox, remoteproc: k3-m4+: fix compile testing

[Mathieu Poirier]

On Mon, Oct 07, 2024 at 01:23:57PM +, Arnd Bergmann wrote:
> From: Arnd Bergmann 
> 
> The k3-m4 remoteproc driver was merged with incorrect dependencies.
> Despite multiple people trying to fix this, the version 6.12-rc2
> remains broken and causes a build failure with CONFIG_TI_SCI_PROTOCOL=m
> when the driver is built-in.
>

(Sigh)

I will do my own testing and will get back to you.

> arm-linux-gnueabi-ld: drivers/remoteproc/ti_k3_m4_remoteproc.o: in function 
> `k3_m4_rproc_probe':
> ti_k3_m4_remoteproc.c:(.text.k3_m4_rproc_probe+0x76): undefined reference to 
> `devm_ti_sci_get_by_phandle'
> 
> Fix the dependency again to make it work in all configurations.
> The 'select OMAP2PLUS_MBOX' no longer matches what the other drivers
> dependencies. The link failure can be avoided with a simple 'depends
> do, so turn that into the same 'depends' to ensure we get no circular
> on TI_SCI_PROTOCOL', but the extra COMPILE_TEST alternative is what
> we use elsehwere. On the other hand, building for OMAP2PLUS makes
> no sense since the hardware only exists on K3.
> 
> Fixes: ebcf9008a895 ("remoteproc: k3-m4: Add a remoteproc driver for M4F 
> subsystem")
> Fixes: ba0c0cb56f22 ("remoteproc: k3-m4: use the proper dependencies")
> Fixes: 54595f2807d2 ("mailbox, remoteproc: omap2+: fix compile testing")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/remoteproc/Kconfig | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index 955e4e38477e..62f8548fb46a 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -341,9 +341,9 @@ config TI_K3_DSP_REMOTEPROC
>  
>  config TI_K3_M4_REMOTEPROC
>   tristate "TI K3 M4 remoteproc support"
> - depends on ARCH_OMAP2PLUS || ARCH_K3
> - select MAILBOX
> - select OMAP2PLUS_MBOX
> + depends on ARCH_K3 || COMPILE_TEST
> + depends on TI_SCI_PROTOCOL || (COMPILE_TEST && TI_SCI_PROTOCOL=n)
> + depends on OMAP2PLUS_MBOX
>   help
> Say m here to support TI's M4 remote processor subsystems
> on various TI K3 family of SoCs through the remote processor
> -- 
> 2.39.2
> 

Re: [PATCH 1/1] remoteproc: Use iommu_paging_domain_alloc()

[Mathieu Poirier]

On Tue, 1 Oct 2024 at 07:35, Jason Gunthorpe  wrote:
>
> On Mon, Sep 30, 2024 at 10:40:30AM -0600, Mathieu Poirier wrote:
> > On Mon, Aug 12, 2024 at 03:28:11PM +0800, Lu Baolu wrote:
> > > An iommu domain is allocated in rproc_enable_iommu() and is attached to
> > > rproc->dev.parent in the same function.
> > >
> > > Use iommu_paging_domain_alloc() to make it explicit.
> > >
> > > Signed-off-by: Lu Baolu 
> > > Reviewed-by: Jason Gunthorpe 
> > > Link: 
> > > https://lore.kernel.org/r/2024061008.88197-13-baolu...@linux.intel.com
> > > ---
> > >  drivers/remoteproc/remoteproc_core.c | 6 +++---
> > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > >
> >
> > I have applied this patch.
>
> It is a bit late now. Can we run the stragglers through the iommu
> tree? We want to put dependent patches on top of this.
>

Sure, we can do that:

Reviewed-by: Mathieu Poirier 

Please send me a pull request so that I can also carry the patch in my tree.

Re: [PATCH] remoteproc: virtio: Add synchronize_cbs to remoteproc_virtio

[Mathieu Poirier]

On Fri, Sep 27, 2024 at 02:51:38AM +, Mark-PK Tsai (蔡沛剛) wrote:
> Hi,
> 
> Could someone help to review it or provide suggestions?
> Any comments are welcome.
> 
> This patch is intended to allow the rproc driver to handle the
> following use-after-free issue:
> 
> 
> ### UAF log

What does "UAF" means?

> [  337.540275][  T470]  virtqueue_add.llvm.10153462284424984632+0xb48/0
> xcc4
> [  337.546969][  T470]  virtqueue_add_inbuf+0x44/0x6c
> <--- vqs are freed in vring_del_virtqueue
> [  337.551755][  T470]  rpmsg_recv_done+0x1fc/0x2c4 [virtio_rpmsg_bus]
> [  337.558023][  T470]  vring_interrupt+0xa0/0xe0
> [  337.562462][  T470]  rproc_vq_interrupt+0x34/0x48
> [  337.567160][  T470]  handle_event+0x28/0x48 [mtk_pqu_rproc]
> [  337.572742][  T470]  irq_thread_fn+0x4c/0xcc
> [  337.577009][  T470]  irq_thread+0x1d0/0x360
> [  337.581189][  T470]  kthread+0x168/0x1cc
> [  337.585107][  T470]  ret_from_fork+0x10/0x20
> 
> ### stack trace of obj free
> [  339.253063][  T470] die_helper:   <-
> vring_del_virtqueue+0x16c/0x198
> [  339.259757][  T470] die_helper:   <- kfree+0x274/0x35c
> [  339.265236][  T470] die_helper:   <-
> vring_del_virtqueue+0x16c/0x198
> [  339.271929][  T470] die_helper:   <-
> rproc_virtio_del_vqs+0x3c/0x58
> [  339.278535][  T470] die_helper:   <- rpmsg_remove+0x8c/0x12c
> [virtio_rpmsg_bus]
> [  339.286189][  T470] die_helper:   <-
> virtio_dev_remove+0x64/0x174
> [  339.292622][  T470] die_helper:   <-
> device_release_driver_internal+0x1a8/0x32c
> [  339.300270][  T470] die_helper:   <-
> bus_remove_device+0x130/0x160
> [  339.306789][  T470] die_helper:   <- device_del+0x224/0x518
> [  339.312702][  T470] die_helper:   <- device_unregister+0x20/0x3c
> [  339.319047][  T470] die_helper:   <-
> rproc_remove_virtio_dev+0x20/0x44
> [  339.325913][  T470] die_helper:   <-
> device_for_each_child+0x84/0x100
> [  339.332696][  T470] die_helper:   <-
> rproc_vdev_do_stop+0x30/0x5c
> [  339.339130][  T470] die_helper:   <- rproc_stop+0xcc/0x200
> 

None of the above is showing me where this use-after-free happens.


> On Fri, 2024-09-20 at 17:16 +0800, Mark-PK Tsai wrote:
> > Add synchornize_cbs to rproc_virtio_config_ops and a
> > synchronize_vqs callback to the rproc_ops to ensure vqs'
> > state changes are visible in vring_interrupts when the vq is
> > broken or removed.
> > 
> > And when VIRTIO_HARDEN_NOTIFICATION is not set, call
> > rproc_virtio_synchronize_cbs directly in __rproc_virtio_del_vqs
> > before virtqueue is free to ensure that rproc_vq_interrupt is
> > aware of the virtqueue removal.
> > 
> > The synchronized_vqs is expected to be implemented in rproc
> > driver to ensure that all previous vring_interrupts are handled
> > before the vqs are marked as broken or removed.
> > 
> > Signed-off-by: Mark-PK Tsai 
> > ---
> >  drivers/remoteproc/remoteproc_virtio.c | 12 
> >  include/linux/remoteproc.h |  4 
> >  2 files changed, 16 insertions(+)
> > 
> > diff --git a/drivers/remoteproc/remoteproc_virtio.c
> > b/drivers/remoteproc/remoteproc_virtio.c
> > index d3f39009b28e..e18258b69851 100644
> > --- a/drivers/remoteproc/remoteproc_virtio.c
> > +++ b/drivers/remoteproc/remoteproc_virtio.c
> > @@ -74,6 +74,14 @@ static bool rproc_virtio_notify(struct virtqueue
> > *vq)
> > return true;
> >  }
> >  
> > +static void rproc_virtio_synchronize_cbs(struct virtio_device *vdev)
> > +{
> > +   struct rproc *rproc = vdev_to_rproc(vdev);
> > +
> > +   if (rproc->ops->synchronize_vqs)
> > +   rproc->ops->synchronize_vqs(rproc);
> > +}
> > +
> >  /**
> >   * rproc_vq_interrupt() - tell remoteproc that a virtqueue is
> > interrupted
> >   * @rproc: handle to the remote processor
> > @@ -171,6 +179,9 @@ static void __rproc_virtio_del_vqs(struct
> > virtio_device *vdev)
> > list_for_each_entry_safe(vq, n, &vdev->vqs, list) {
> > rvring = vq->priv;
> > rvring->vq = NULL;
> > +#ifndef CONFIG_VIRTIO_HARDEN_NOTIFICATION
> > +   rproc_virtio_synchronize_cbs(vdev);
> > +#endif
> > vring_del_virtqueue(vq);
> > }
> >  }
> > @@ -334,6 +345,7 @@ static const struct virtio_config_ops
> > rproc_virtio_config_ops = {
> > .get_status = rproc_virtio_get_status,
> > .get= rproc_virtio_get,
> > .set= rproc_virtio_set,
> > +   .synchronize_cbs = rproc_virtio_synchronize_cbs,

Where and when is this called?

This patch is very confusing and doesn't have a user.  As such it is
impossible for me to understand what is going on.  

Thanks,
Mathieu

> >  };
> >  
> >  /*
> > diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
> > index b4795698d8c2..73901678ac7d 100644
> > --- a/include/linux/remoteproc.h
> > +++ b/include/linux/remoteproc.h
> > @@ -381,6 +381,9 @@ enum rsc_handling_status {
> >   * @panic: optional callback to react to system panic, core will
> > delay
> >   * panic at lea

Re: [PATCH] remoteproc: k3: Call of_node_put(rmem_np) only once in three functions

[Mathieu Poirier]

On Tue, Sep 24, 2024 at 02:43:40PM +0200, Markus Elfring wrote:
> From: Markus Elfring 
> Date: Tue, 24 Sep 2024 14:28:35 +0200
> 
> An of_node_put(rmem_np) call was immediately used after a pointer check
> for a of_reserved_mem_lookup() call in three function implementations.
> Thus call such a function only once instead directly before the checks.
> 
> This issue was transformed by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 
> ---
>  drivers/remoteproc/ti_k3_dsp_remoteproc.c | 6 ++
>  drivers/remoteproc/ti_k3_m4_remoteproc.c  | 6 ++
>  drivers/remoteproc/ti_k3_r5_remoteproc.c  | 3 +--
>  3 files changed, 5 insertions(+), 10 deletions(-)
>

Applied.

Thanks,
Mathieu

> diff --git a/drivers/remoteproc/ti_k3_dsp_remoteproc.c 
> b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
> index 8be3f631c192..d08a3a98ada1 100644
> --- a/drivers/remoteproc/ti_k3_dsp_remoteproc.c
> +++ b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
> @@ -576,11 +576,9 @@ static int k3_dsp_reserved_mem_init(struct k3_dsp_rproc 
> *kproc)
>   return -EINVAL;
> 
>   rmem = of_reserved_mem_lookup(rmem_np);
> - if (!rmem) {
> - of_node_put(rmem_np);
> - return -EINVAL;
> - }
>   of_node_put(rmem_np);
> + if (!rmem)
> + return -EINVAL;
> 
>   kproc->rmem[i].bus_addr = rmem->base;
>   /* 64-bit address regions currently not supported */
> diff --git a/drivers/remoteproc/ti_k3_m4_remoteproc.c 
> b/drivers/remoteproc/ti_k3_m4_remoteproc.c
> index 09f0484a90e1..a16fb165fced 100644
> --- a/drivers/remoteproc/ti_k3_m4_remoteproc.c
> +++ b/drivers/remoteproc/ti_k3_m4_remoteproc.c
> @@ -433,11 +433,9 @@ static int k3_m4_reserved_mem_init(struct k3_m4_rproc 
> *kproc)
>   return -EINVAL;
> 
>   rmem = of_reserved_mem_lookup(rmem_np);
> - if (!rmem) {
> - of_node_put(rmem_np);
> - return -EINVAL;
> - }
>   of_node_put(rmem_np);
> + if (!rmem)
> + return -EINVAL;
> 
>   kproc->rmem[i].bus_addr = rmem->base;
>   /* 64-bit address regions currently not supported */
> diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c 
> b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> index 747ee467da88..d0ebdd5cfa70 100644
> --- a/drivers/remoteproc/ti_k3_r5_remoteproc.c
> +++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> @@ -1001,12 +1001,11 @@ static int k3_r5_reserved_mem_init(struct k3_r5_rproc 
> *kproc)
>   }
> 
>   rmem = of_reserved_mem_lookup(rmem_np);
> + of_node_put(rmem_np);
>   if (!rmem) {
> - of_node_put(rmem_np);
>   ret = -EINVAL;
>   goto unmap_rmem;
>   }
> - of_node_put(rmem_np);
> 
>   kproc->rmem[i].bus_addr = rmem->base;
>   /*
> --
> 2.46.1
> 

Re: [PATCH 1/1] remoteproc: Use iommu_paging_domain_alloc()

[Mathieu Poirier]

On Mon, Aug 12, 2024 at 03:28:11PM +0800, Lu Baolu wrote:
> An iommu domain is allocated in rproc_enable_iommu() and is attached to
> rproc->dev.parent in the same function.
> 
> Use iommu_paging_domain_alloc() to make it explicit.
> 
> Signed-off-by: Lu Baolu 
> Reviewed-by: Jason Gunthorpe 
> Link: 
> https://lore.kernel.org/r/2024061008.88197-13-baolu...@linux.intel.com
> ---
>  drivers/remoteproc/remoteproc_core.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>

I have applied this patch.

Thanks,
Mathieu

> diff --git a/drivers/remoteproc/remoteproc_core.c 
> b/drivers/remoteproc/remoteproc_core.c
> index f276956f2c5c..eb66f78ec8b7 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -109,10 +109,10 @@ static int rproc_enable_iommu(struct rproc *rproc)
>   return 0;
>   }
>  
> - domain = iommu_domain_alloc(dev->bus);
> - if (!domain) {
> + domain = iommu_paging_domain_alloc(dev);
> + if (IS_ERR(domain)) {
>   dev_err(dev, "can't alloc iommu domain\n");
> - return -ENOMEM;
> + return PTR_ERR(domain);
>   }
>  
>   iommu_set_fault_handler(domain, rproc_iommu_fault, rproc);
> -- 
> 2.34.1
> 

Re: [GIT PULL] remoteproc updates for v6.12

[Mathieu Poirier]

On Tue, Sep 24, 2024 at 12:52:42PM -0700, Linus Torvalds wrote:
> On Tue, 24 Sept 2024 at 12:31, Linus Torvalds
>  wrote:
> >
> > It's in my tree now, but please fix asap.
> 
> Argh, now that I noticed it, I can no longer unsee it.
> 
> So I did this
> 
> -   depends on ARCH_K3 || COMPILE_TEST
> +   depends on ARCH_OMAP2PLUS || ARCH_K3
>

Thank you for doing this and apologies for the late reply.

Mathieu

> to the TI_K3_M4_REMOTEPROC entry so that it wouldn't try to select
> OMAP2PLUS_MBOX in conditions where it isn't valid.
> 
> Linus

Re: [PATCH v9 4/7] remoteproc: core: Add TEE interface support for firmware release

[Mathieu Poirier]

On Wed, Sep 18, 2024 at 04:43:32PM +0200, Arnaud POULIQUEN wrote:
> Hello Mathieu,
> 
> On 8/30/24 11:51, Arnaud Pouliquen wrote:
> > Add support for releasing remote processor firmware through
> > the Trusted Execution Environment (TEE) interface.
> > 
> > The tee_rproc_release_fw() function is called in the following cases:
> > 
> > - An error occurs in rproc_start() between the loading of the segments and
> >   the start of the remote processor.
> > - When rproc_release_fw is called on error or after stopping the remote
> >   processor.
> > 
> > Signed-off-by: Arnaud Pouliquen 
> > ---
> >  drivers/remoteproc/remoteproc_core.c | 10 --
> >  1 file changed, 8 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/remoteproc/remoteproc_core.c 
> > b/drivers/remoteproc/remoteproc_core.c
> > index 7694817f25d4..32052dedc149 100644
> > --- a/drivers/remoteproc/remoteproc_core.c
> > +++ b/drivers/remoteproc/remoteproc_core.c
> > @@ -29,6 +29,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -1258,6 +1259,9 @@ static int rproc_alloc_registered_carveouts(struct 
> > rproc *rproc)
> >  
> >  static void rproc_release_fw(struct rproc *rproc)
> >  {
> > +   if (rproc->state == RPROC_OFFLINE && rproc->tee_interface)
> > +   tee_rproc_release_fw(rproc);
> 
> I'm requesting you expertise to fix an issue I'm facing during my test 
> preparing
> the V10.
> 
> My issue is that here, we can call the tee_rproc_release_fw() function, 
> defined
> in remoteproc_tee built as a remoteproc_tee.ko module.
> 
> I tried to use the IS_ENABLED and IS_REACHABLE macros in remoteproc_tee.h, but
> without success:
> - use IS_ENABLED() results in a link error: "undefined reference to
> tee_rproc_release_fw."
> - use IS_REACHABLE() returns false and remoteproc_core calls the inline
> tee_rproc_release_fw function that just call WARN_ON(1).
> 
> To solve the issue, I can see three alternatives:
> 
> 1) Modify Kconfig and remoteproc_tee.c to support only built-in.
> 2) Use symbol_get/symbol_put.
> 3) Define a new rproc_ops->release_fw operation that will be initialized to
> tee_rproc_release_fw.
>

Option (1) is best but make sure people can disable the TEE interface if they
don't wish to use it.

> From my perspective, the solution 3 seems to be the cleanest way, as it also
> removes the dependency between remoteproc_core.c and remoteproc_tee.c. But
> regarding previous discussion/series version, it seems that it could not be 
> your
> preferred solution.
> 
> Please, could you indicate your preference so that I can directly implement 
> the
> best solution (or perhaps you have another alternative to propose)?
> 
> Thanks in advance!
> 
> Arnaud
> 
> 
> > +
> > /* Free the copy of the resource table */
> > kfree(rproc->cached_table);
> > rproc->cached_table = NULL;
> > @@ -1348,7 +1352,7 @@ static int rproc_start(struct rproc *rproc, const 
> > struct firmware *fw)
> > if (ret) {
> > dev_err(dev, "failed to prepare subdevices for %s: %d\n",
> > rproc->name, ret);
> > -   goto reset_table_ptr;
> > +   goto release_fw;
> > }
> >  
> > /* power up the remote processor */
> > @@ -1376,7 +1380,9 @@ static int rproc_start(struct rproc *rproc, const 
> > struct firmware *fw)
> > rproc->ops->stop(rproc);
> >  unprepare_subdevices:
> > rproc_unprepare_subdevices(rproc);
> > -reset_table_ptr:
> > +release_fw:
> > +   if (rproc->tee_interface)
> > +   tee_rproc_release_fw(rproc);
> > rproc->table_ptr = rproc->cached_table;
> >  
> > return ret;

Re: [PATCH v9 4/7] remoteproc: core: Add TEE interface support for firmware release

[Mathieu Poirier]

On Tue, Sep 17, 2024 at 06:56:58PM +0200, Arnaud POULIQUEN wrote:
> Hello Mathieu,
> 
> On 9/12/24 17:26, Mathieu Poirier wrote:
> > On Fri, Aug 30, 2024 at 11:51:44AM +0200, Arnaud Pouliquen wrote:
> >> Add support for releasing remote processor firmware through
> >> the Trusted Execution Environment (TEE) interface.
> >>
> >> The tee_rproc_release_fw() function is called in the following cases:
> >>
> >> - An error occurs in rproc_start() between the loading of the segments and
> >>   the start of the remote processor.
> >> - When rproc_release_fw is called on error or after stopping the remote
> >>   processor.
> >>
> >> Signed-off-by: Arnaud Pouliquen 
> >> ---
> >>  drivers/remoteproc/remoteproc_core.c | 10 --
> >>  1 file changed, 8 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/remoteproc/remoteproc_core.c 
> >> b/drivers/remoteproc/remoteproc_core.c
> >> index 7694817f25d4..32052dedc149 100644
> >> --- a/drivers/remoteproc/remoteproc_core.c
> >> +++ b/drivers/remoteproc/remoteproc_core.c
> >> @@ -29,6 +29,7 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>  #include 
> >>  #include 
> >>  #include 
> >> @@ -1258,6 +1259,9 @@ static int rproc_alloc_registered_carveouts(struct 
> >> rproc *rproc)
> >>  
> >>  static void rproc_release_fw(struct rproc *rproc)
> >>  {
> >> +  if (rproc->state == RPROC_OFFLINE && rproc->tee_interface)
> >> +  tee_rproc_release_fw(rproc);
> > 
> > Function tee_rproc_release_fw() returns a value that is ignored.  I don't 
> > know
> > how it passes the Sparse checker but I already see patches coming in my 
> > Inbox to
> > deal with that.  In this case there is nothing else to do if there is an 
> > error
> > releasing the firware.  As such I would put a (void) in front and add a 
> > comment
> > about the return value being ignore on purpose.
> 
> Instead of ignoring the error, I wonder if we should panic in
> tee_rproc_release_fw(). Indeed, we would be in an unexpected state without any
> possible action to return to a normal state.

Nowadays a call to panic() is only used in very dire situations and I don't see
this meeting that requirement.  I would just call a dev_err() and let it be.

> 
> Regards,
> Arnaud
> 
> > 
> >> +
> >>/* Free the copy of the resource table */
> >>kfree(rproc->cached_table);
> >>rproc->cached_table = NULL;
> >> @@ -1348,7 +1352,7 @@ static int rproc_start(struct rproc *rproc, const 
> >> struct firmware *fw)
> >>if (ret) {
> >>dev_err(dev, "failed to prepare subdevices for %s: %d\n",
> >>rproc->name, ret);
> >> -  goto reset_table_ptr;
> >> +  goto release_fw;
> >>}
> >>  
> >>/* power up the remote processor */
> >> @@ -1376,7 +1380,9 @@ static int rproc_start(struct rproc *rproc, const 
> >> struct firmware *fw)
> >>rproc->ops->stop(rproc);
> >>  unprepare_subdevices:
> >>rproc_unprepare_subdevices(rproc);
> >> -reset_table_ptr:
> >> +release_fw:
> >> +  if (rproc->tee_interface)
> >> +  tee_rproc_release_fw(rproc);
> > 
> > Same here.
> > 
> >>rproc->table_ptr = rproc->cached_table;
> >>  
> >>return ret;
> >> -- 
> >> 2.25.1
> >>

Re: [RFC PATCH] remoteproc: k3-r5: Fix check performed in k3_r5_rproc_{mbox_callback/kick}

[Mathieu Poirier]

On Tue, 17 Sept 2024 at 03:13, Kumar, Udit  wrote:
>
> Hi Mathieu,
>
> On 9/17/2024 2:07 PM, Mathieu Poirier wrote:
> > On Mon, 16 Sept 2024 at 23:20, Kumar, Udit  wrote:
> >> On 9/16/2024 8:50 PM, Mathieu Poirier wrote:
> >>> On Mon, 16 Sept 2024 at 02:31, Siddharth Vadapalli  
> >>> wrote:
> >>>> Commit f3f11cfe8907 ("remoteproc: k3-r5: Acquire mailbox handle during
> >>>> probe routine") introduced a check in the "k3_r5_rproc_mbox_callback()" 
> >>>> and
> >>>> "k3_r5_rproc_kick()" callbacks, causing them to exit if the remote core's
> >>>> state is "RPROC_DETACHED". However, the "__rproc_attach()" function that 
> >>>> is
> >>>> responsible for attaching to a remote core, updates the state of the 
> >>>> remote
> >>>> core to "RPROC_ATTACHED" only after invoking "rproc_start_subdevices()".
> >>>>
> >>>> The "rproc_start_subdevices()" function triggers the probe of the Virtio
> >>>> RPMsg devices associated with the remote core, which require that the
> >>>> "k3_r5_rproc_kick()" and "k3_r5_rproc_mbox_callback()" callbacks are
> >>>> functional. Hence, drop the check in the callbacks.
> >>> Honestly, I am very tempted to just revert f3f11cfe8907 and ea1d6fb5b571.
> >>
> >> Please don't :) , it will break rproc in general for k3 devices.
> >>
> > Why not - it is already broken anyway.  Reverting the patches will
> > force TI to actually think about the feature in terms of design,
> > completeness and testing.  The merge window opened on Sunday - I'm not
> > going to merge whack-a-mole patches and hope the right fix comes
> > along.
>
> Now, I am not advocating here to revert or not.
>
> But where we stand currently
>
> 1-  Without this patch, IPC is broken in general.
>
> 2-  With this patch, IPC is conditionally broken.
>
> In either case, we need to fix it.
>
> your call to revert or keep it.
>

I will keep f3f11cfe8907 and ea1d6fb5b571 but will not take this one
because 1) we are in the merge window and 2) I have no assurance that
this is the right (and complete) fix.

>
> >
> >> Couple of solutions for this race around condition (in mine preference
> >> order)
> >>
> > This is for the TI team to discuss _and_ test thoroughly.  From hereon
> > and until I see things improve, all patches from TI will need to be
> > tagged with R-B and T-B tags (collected on the mailing lists) from two
> > different individuals before I look at them.
>
> Sure we will take care of above
>
> and fair ask on R-B and T-B tags
>
> >
> >> 1) In
> >> https://elixir.bootlin.com/linux/v6.11/source/drivers/remoteproc/ti_k3_r5_remoteproc.c#L190
> >> have a check , if probe in is progress or not
> >>
> >> 2)
> >> https://elixir.bootlin.com/linux/v6.11/source/drivers/remoteproc/ti_k3_r5_remoteproc.c#L1205
> >> -- correct the state to ON or something else
> >>
> >> 3) Move condition
> >> https://elixir.bootlin.com/linux/v6.11/source/drivers/remoteproc/remoteproc_core.c#L1360
> >> before rproc_start_subdevices
> >> <https://elixir.bootlin.com/linux/v6.11/C/ident/rproc_start_subdevices>
> >> calling
> >>
> >>
> >>
> >>>> Fixes: f3f11cfe8907 ("remoteproc: k3-r5: Acquire mailbox handle during 
> >>>> probe routine")
> >>>> Signed-off-by: Siddharth Vadapalli 
> >>>> ---
> >>>>
> >>>> Hello,
> >>>>
> >>>> Since the commit being fixed is not yet a part of Mainline Linux, this
> >>>> patch is based on linux-next tagged next-20240913.
> >>>>
> >>>> An alternative to this patch will be a change to the "__rproc_attach()"
> >>>> function in the "remoteproc_core.c" driver with
> >>>> rproc->state = RPROC_ATTACHED;
> >>>> being set after "rproc_attach_device()" is invoked, but __before__
> >>>> invoking "rproc_start_subdevices()". Since this change will be performed
> >>>> in the common Remoteproc Core, it appeared to me that fixing it in the
> >>>> TI remoteproc driver is the correct approach.
> >>>>
> >>>> The equivalent of this patch for ti_k3_dsp_remoteproc.c might also be
> >>>> required, wh

Re: [RFC PATCH] remoteproc: k3-r5: Fix check performed in k3_r5_rproc_{mbox_callback/kick}

[Mathieu Poirier]

s

On Tue, 17 Sept 2024 at 03:40, Beleswar Prasad Padhi  wrote:
>
> Hi Mathieu,
>
> On 17/09/24 14:07, Mathieu Poirier wrote:
> > On Mon, 16 Sept 2024 at 23:20, Kumar, Udit  wrote:
> >> On 9/16/2024 8:50 PM, Mathieu Poirier wrote:
> >>> On Mon, 16 Sept 2024 at 02:31, Siddharth Vadapalli  
> >>> wrote:
> >>>> Commit f3f11cfe8907 ("remoteproc: k3-r5: Acquire mailbox handle during
> >>>> probe routine") introduced a check in the "k3_r5_rproc_mbox_callback()" 
> >>>> and
> >>>> "k3_r5_rproc_kick()" callbacks, causing them to exit if the remote core's
> >>>> state is "RPROC_DETACHED". However, the "__rproc_attach()" function that 
> >>>> is
> >>>> responsible for attaching to a remote core, updates the state of the 
> >>>> remote
> >>>> core to "RPROC_ATTACHED" only after invoking "rproc_start_subdevices()".
> >>>>
> >>>> The "rproc_start_subdevices()" function triggers the probe of the Virtio
> >>>> RPMsg devices associated with the remote core, which require that the
> >>>> "k3_r5_rproc_kick()" and "k3_r5_rproc_mbox_callback()" callbacks are
> >>>> functional. Hence, drop the check in the callbacks.
> >>> Honestly, I am very tempted to just revert f3f11cfe8907 and ea1d6fb5b571.
> >>
> >> Please don't :) , it will break rproc in general for k3 devices.
> >>
> > Why not - it is already broken anyway.  Reverting the patches will
> > force TI to actually think about the feature in terms of design,
> > completeness and testing.  The merge window opened on Sunday - I'm not
> > going to merge whack-a-mole patches and hope the right fix comes
> > along.
>
>
> Apologies for causing this trouble, Mathieu. I have accumulated various
> use-cases of the driver, including this, and hereon will keep in mind
> while posting further patches.
>
> >
> >> Couple of solutions for this race around condition (in mine preference
> >> order)
> >>
> > This is for the TI team to discuss _and_ test thoroughly.  From hereon
> > and until I see things improve, all patches from TI will need to be
> > tagged with R-B and T-B tags (collected on the mailing lists) from two
> > different individuals before I look at them.
>
>
> Understood, that is a fair ask. Hereon, I will also attach my test logs
> for all the usecases I've tested a patch with, to give more visibility
> on the testing done.
>

I am not in a position (nor have the time) to look at test logs and as
such, there is no point in doing that.  That time should be better
spent building a CI that goes through all the scenarios and making
sure that all patches pass the tests before being sent to the mailing
list.

> >
> >> 1) In
> >> https://elixir.bootlin.com/linux/v6.11/source/drivers/remoteproc/ti_k3_r5_remoteproc.c#L190
> >> have a check , if probe in is progress or not
> >>
> >> 2)
> >> https://elixir.bootlin.com/linux/v6.11/source/drivers/remoteproc/ti_k3_r5_remoteproc.c#L1205
> >> -- correct the state to ON or something else
> >>
> >> 3) Move condition
> >> https://elixir.bootlin.com/linux/v6.11/source/drivers/remoteproc/remoteproc_core.c#L1360
> >> before rproc_start_subdevices
> >> <https://elixir.bootlin.com/linux/v6.11/C/ident/rproc_start_subdevices>
> >> calling
> >>
> >>
> >>
> >>>> Fixes: f3f11cfe8907 ("remoteproc: k3-r5: Acquire mailbox handle during 
> >>>> probe routine")
> >>>> Signed-off-by: Siddharth Vadapalli 
> >>>> ---
> >>>>
> >>>> Hello,
> >>>>
> >>>> Since the commit being fixed is not yet a part of Mainline Linux, this
> >>>> patch is based on linux-next tagged next-20240913.
> >>>>
> >>>> An alternative to this patch will be a change to the "__rproc_attach()"
> >>>> function in the "remoteproc_core.c" driver with
> >>>> rproc->state = RPROC_ATTACHED;
> >>>> being set after "rproc_attach_device()" is invoked, but __before__
> >>>> invoking "rproc_start_subdevices()". Since this change will be performed
> >>>> in the common Remoteproc Core, it appeared to me that fixing it in the
> >>>> TI remoteproc driver is the correct approach.
> >>>>
&g

Re: [PATCH v2 5/5] remoteproc: arm64: corstone1000: Add the External Systems driver

[Mathieu Poirier]

On Wed, 18 Sept 2024 at 09:40, Abdellatif El Khlifi
 wrote:
>
> Hi Mathieu,
>
> > Introduce remoteproc support for Corstone-1000 external systems
> >
> > The Corstone-1000 IoT Reference Design Platform supports up to two
> > external systems processors. These processors can be switched on or off
> > using their reset registers.
> >
> > For more details, please see the SSE-710 External System Remote
> > Processor binding [1] and the SSE-710 Host Base System Control binding [2].
> >
> > The reset registers are MMIO mapped registers accessed using regmap.
> >
> > [1]: Documentation/devicetree/bindings/remoteproc/arm,sse710-extsys.yaml
> > [2]: Documentation/devicetree/bindings/arm/arm,sse710-host-base-sysctrl.yaml
> >
> > Signed-off-by: Abdellatif El Khlifi 
> > ---
> >  drivers/remoteproc/Kconfig  |  14 +
> >  drivers/remoteproc/Makefile |   1 +
> >  drivers/remoteproc/corstone1000_rproc.c | 350 
> >  3 files changed, 365 insertions(+)
>
> A gentle reminder about reviewing the driver please.
>
> I'll be addressing the comments made for the bindings.

Please address the comments already received for the bindings.  I will
review this set once the bindings have settled.

Thanks,
Mathieu

>
> Thank you in advance.
>
> Cheers,
> Abdellatif

Re: [RFC PATCH] remoteproc: k3-r5: Fix check performed in k3_r5_rproc_{mbox_callback/kick}

[Mathieu Poirier]

On Mon, 16 Sept 2024 at 23:20, Kumar, Udit  wrote:
>
> On 9/16/2024 8:50 PM, Mathieu Poirier wrote:
> > On Mon, 16 Sept 2024 at 02:31, Siddharth Vadapalli  
> > wrote:
> >> Commit f3f11cfe8907 ("remoteproc: k3-r5: Acquire mailbox handle during
> >> probe routine") introduced a check in the "k3_r5_rproc_mbox_callback()" and
> >> "k3_r5_rproc_kick()" callbacks, causing them to exit if the remote core's
> >> state is "RPROC_DETACHED". However, the "__rproc_attach()" function that is
> >> responsible for attaching to a remote core, updates the state of the remote
> >> core to "RPROC_ATTACHED" only after invoking "rproc_start_subdevices()".
> >>
> >> The "rproc_start_subdevices()" function triggers the probe of the Virtio
> >> RPMsg devices associated with the remote core, which require that the
> >> "k3_r5_rproc_kick()" and "k3_r5_rproc_mbox_callback()" callbacks are
> >> functional. Hence, drop the check in the callbacks.
> > Honestly, I am very tempted to just revert f3f11cfe8907 and ea1d6fb5b571.
>
>
> Please don't :) , it will break rproc in general for k3 devices.
>

Why not - it is already broken anyway.  Reverting the patches will
force TI to actually think about the feature in terms of design,
completeness and testing.  The merge window opened on Sunday - I'm not
going to merge whack-a-mole patches and hope the right fix comes
along.

> Couple of solutions for this race around condition (in mine preference
> order)
>

This is for the TI team to discuss _and_ test thoroughly.  From hereon
and until I see things improve, all patches from TI will need to be
tagged with R-B and T-B tags (collected on the mailing lists) from two
different individuals before I look at them.

> 1) In
> https://elixir.bootlin.com/linux/v6.11/source/drivers/remoteproc/ti_k3_r5_remoteproc.c#L190
> have a check , if probe in is progress or not
>
> 2)
> https://elixir.bootlin.com/linux/v6.11/source/drivers/remoteproc/ti_k3_r5_remoteproc.c#L1205
> -- correct the state to ON or something else
>
> 3) Move condition
> https://elixir.bootlin.com/linux/v6.11/source/drivers/remoteproc/remoteproc_core.c#L1360
> before rproc_start_subdevices
> <https://elixir.bootlin.com/linux/v6.11/C/ident/rproc_start_subdevices>
> calling
>
>
>
> >
> >> Fixes: f3f11cfe8907 ("remoteproc: k3-r5: Acquire mailbox handle during 
> >> probe routine")
> >> Signed-off-by: Siddharth Vadapalli 
> >> ---
> >>
> >> Hello,
> >>
> >> Since the commit being fixed is not yet a part of Mainline Linux, this
> >> patch is based on linux-next tagged next-20240913.
> >>
> >> An alternative to this patch will be a change to the "__rproc_attach()"
> >> function in the "remoteproc_core.c" driver with
> >> rproc->state = RPROC_ATTACHED;
> >> being set after "rproc_attach_device()" is invoked, but __before__
> >> invoking "rproc_start_subdevices()". Since this change will be performed
> >> in the common Remoteproc Core, it appeared to me that fixing it in the
> >> TI remoteproc driver is the correct approach.
> >>
> >> The equivalent of this patch for ti_k3_dsp_remoteproc.c might also be
> >> required, which I shall post if the current patch is acceptable.
> >>
> >> Kindly review and share your feedback on this patch.
> >>
> >> Regards,
> >> Siddharth.
> >>
> >>   drivers/remoteproc/ti_k3_r5_remoteproc.c | 8 
> >>   1 file changed, 8 deletions(-)
> >>
> >> diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c 
> >> b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> >> index 747ee467da88..4894461aa65f 100644
> >> --- a/drivers/remoteproc/ti_k3_r5_remoteproc.c
> >> +++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> >> @@ -194,10 +194,6 @@ static void k3_r5_rproc_mbox_callback(struct 
> >> mbox_client *client, void *data)
> >>  const char *name = kproc->rproc->name;
> >>  u32 msg = omap_mbox_message(data);
> >>
> >> -   /* Do not forward message from a detached core */
> >> -   if (kproc->rproc->state == RPROC_DETACHED)
> >> -   return;
> >> -
> >>  dev_dbg(dev, "mbox msg: 0x%x\n", msg);
> >>
> >>  switch (msg) {
> >> @@ -233,10 +229,6 @@ static void k3_r5_rproc_kick(struct rproc *rproc, int 
> >> vqid)
> >>  mbox_msg_t msg = (mbox_msg_t)vqid;
> >>  int ret;
> >>
> >> -   /* Do not forward message to a detached core */
> >> -   if (kproc->rproc->state == RPROC_DETACHED)
> >> -   return;
> >> -
> >>  /* send the index of the triggered virtqueue in the mailbox 
> >> payload */
> >>  ret = mbox_send_message(kproc->mbox, (void *)msg);
> >>  if (ret < 0)
> >> --
> >> 2.40.1
> >>

Re: [PATCH 1/1] remoteproc: Use iommu_paging_domain_alloc()

[Mathieu Poirier]

On Sun, 15 Sept 2024 at 08:09, Jason Gunthorpe  wrote:
>
> On Thu, Aug 22, 2024 at 01:24:25PM -0300, Jason Gunthorpe wrote:
> > On Thu, Aug 22, 2024 at 10:17:56AM -0600, Mathieu Poirier wrote:
> >
> > > > - domain = iommu_domain_alloc(dev->bus);
> > > > - if (!domain) {
> > > > + domain = iommu_paging_domain_alloc(dev);
> > >
> > > I'm a little hesitant here.  Function iommu_domain_alloc() passes NULL 
> > > two the
> > > second argument of __iommu_domain_alloc() while 
> > > iommu_paging_domain_alloc()
> > > provides a 'dev'.  I don't have any HW to test on and I am not familiar 
> > > enough
> > > with the IOMMU subsystem to confidently more forward.
> >
> > So long as dev is the device that will be initiating DMA this is a
> > correct change from the iommu subsystem perspective.
>
> This is the only call site left for iommu_domain_alloc() - we want to
> remove this API on the next cycle. Please take the patch
>

And I have no intentions of delaying things further.  I will discuss
this with Bjorn later this week in Vienna.

> Thanks,
> Jason

Re: [RFC PATCH] remoteproc: k3-r5: Fix check performed in k3_r5_rproc_{mbox_callback/kick}

[Mathieu Poirier]

On Mon, 16 Sept 2024 at 02:31, Siddharth Vadapalli  wrote:
>
> Commit f3f11cfe8907 ("remoteproc: k3-r5: Acquire mailbox handle during
> probe routine") introduced a check in the "k3_r5_rproc_mbox_callback()" and
> "k3_r5_rproc_kick()" callbacks, causing them to exit if the remote core's
> state is "RPROC_DETACHED". However, the "__rproc_attach()" function that is
> responsible for attaching to a remote core, updates the state of the remote
> core to "RPROC_ATTACHED" only after invoking "rproc_start_subdevices()".
>
> The "rproc_start_subdevices()" function triggers the probe of the Virtio
> RPMsg devices associated with the remote core, which require that the
> "k3_r5_rproc_kick()" and "k3_r5_rproc_mbox_callback()" callbacks are
> functional. Hence, drop the check in the callbacks.

Honestly, I am very tempted to just revert f3f11cfe8907 and ea1d6fb5b571.

>
> Fixes: f3f11cfe8907 ("remoteproc: k3-r5: Acquire mailbox handle during probe 
> routine")
> Signed-off-by: Siddharth Vadapalli 
> ---
>
> Hello,
>
> Since the commit being fixed is not yet a part of Mainline Linux, this
> patch is based on linux-next tagged next-20240913.
>
> An alternative to this patch will be a change to the "__rproc_attach()"
> function in the "remoteproc_core.c" driver with
> rproc->state = RPROC_ATTACHED;
> being set after "rproc_attach_device()" is invoked, but __before__
> invoking "rproc_start_subdevices()". Since this change will be performed
> in the common Remoteproc Core, it appeared to me that fixing it in the
> TI remoteproc driver is the correct approach.
>
> The equivalent of this patch for ti_k3_dsp_remoteproc.c might also be
> required, which I shall post if the current patch is acceptable.
>
> Kindly review and share your feedback on this patch.
>
> Regards,
> Siddharth.
>
>  drivers/remoteproc/ti_k3_r5_remoteproc.c | 8 
>  1 file changed, 8 deletions(-)
>
> diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c 
> b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> index 747ee467da88..4894461aa65f 100644
> --- a/drivers/remoteproc/ti_k3_r5_remoteproc.c
> +++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> @@ -194,10 +194,6 @@ static void k3_r5_rproc_mbox_callback(struct mbox_client 
> *client, void *data)
> const char *name = kproc->rproc->name;
> u32 msg = omap_mbox_message(data);
>
> -   /* Do not forward message from a detached core */
> -   if (kproc->rproc->state == RPROC_DETACHED)
> -   return;
> -
> dev_dbg(dev, "mbox msg: 0x%x\n", msg);
>
> switch (msg) {
> @@ -233,10 +229,6 @@ static void k3_r5_rproc_kick(struct rproc *rproc, int 
> vqid)
> mbox_msg_t msg = (mbox_msg_t)vqid;
> int ret;
>
> -   /* Do not forward message to a detached core */
> -   if (kproc->rproc->state == RPROC_DETACHED)
> -   return;
> -
> /* send the index of the triggered virtqueue in the mailbox payload */
> ret = mbox_send_message(kproc->mbox, (void *)msg);
> if (ret < 0)
> --
> 2.40.1
>

Re: [PATCH v1 0/5] Add Microchip IPC mailbox and remoteproc support

[Mathieu Poirier]

Hi Valentina,

On Thu, 12 Sept 2024 at 10:48, Valentina Fernandez
 wrote:
>
> Hello all,
>
> This series adds support for the Microchip Inter-Processor Communication
> (IPC) mailbox controller, as well as an IPC remoteproc platform driver.
>
> Microchip's family of RISC-V SoCs typically has one or more clusters
> that can be configured to run in Asymmetric Multi-Processing (AMP) mode.
>
> The Microchip IPC is used to send messages between processors using
> an interrupt signaling mechanism. The driver uses the RISC-V Supervisor
> Binary Interface (SBI) to communicate with software running in machine
> mode (M-mode) to access the IPC hardware block.
>
> Additional details on the Microchip vendor extension and the IPC
> function IDs described in the driver can be found in the following
> documentation:
>
> https://github.com/linux4microchip/microchip-sbi-ecall-extension
>
> The IPC remoteproc platform driver allows for starting and stopping
> firmware on the remote cluster(s) and facilitates RPMsg communication.
> The remoteproc attach/detach operations are also supported for use cases
> where the firmware is loaded by the Hart Software Services
> (zero-stage bootloader) before Linux boots.
>
> Error Recovery and Power Management features are not currently
> supported in the remoteproc platform driver.
>
> The PIC64GX MPU has a Mi-V IHC block, this will be added to the PIC64GX
> dts after the initial upstreaming:
>
> https://patchwork.kernel.org/project/linux-riscv/patch/20240725121609.13101-18-pierre-henry.mous...@microchip.com/
>
> Thanks,
> Valentina
>
> Valentina Fernandez (5):
>   riscv: asm: vendorid_list: Add Microchip Technology to the vendor list
>   dt-bindings: mailbox: add binding for Microchip IPC mailbox driver
>   mailbox: add Microchip IPC support
>   dt-bindings: remoteproc: add binding for Microchip IPC remoteproc
>   remoteproc: add support for Microchip IPC remoteproc platform driver
>
>  .../bindings/mailbox/microchip,sbi-ipc.yaml   | 115 
>  .../remoteproc/microchip,ipc-remoteproc.yaml  |  84 +++
>  arch/riscv/include/asm/vendorid_list.h|   1 +
>  drivers/mailbox/Kconfig   |  12 +
>  drivers/mailbox/Makefile  |   2 +
>  drivers/mailbox/mailbox-mchp-ipc-sbi.c| 539 ++
>  drivers/remoteproc/Kconfig|  12 +
>  drivers/remoteproc/Makefile   |   1 +
>  drivers/remoteproc/mchp_ipc_remoteproc.c  | 461 +++
>  include/linux/mailbox/mchp-ipc.h  |  23 +

I would advise splitting the two patchsets, i.e one for the mailbox
driver and another one for the remoteproc.  I would also start with
the mailbox and then go with the remoteproc.

Thanks,
Mathieu

>  10 files changed, 1250 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/mailbox/microchip,sbi-ipc.yaml
>  create mode 100644 
> Documentation/devicetree/bindings/remoteproc/microchip,ipc-remoteproc.yaml
>  create mode 100644 drivers/mailbox/mailbox-mchp-ipc-sbi.c
>  create mode 100644 drivers/remoteproc/mchp_ipc_remoteproc.c
>  create mode 100644 include/linux/mailbox/mchp-ipc.h
>
> --
> 2.34.1
>

Re: [PATCH v9 7/7] remoteproc: stm32: Add support of an OP-TEE TA to load the firmware

[Mathieu Poirier]

On Fri, Aug 30, 2024 at 11:51:47AM +0200, Arnaud Pouliquen wrote:
> The new TEE remoteproc driver is used to manage remote firmware in a
> secure, trusted context. The 'st,stm32mp1-m4-tee' compatibility is
> introduced to delegate the loading of the firmware to the trusted
> execution context. In such cases, the firmware should be signed and
> adhere to the image format defined by the TEE.
> 
> Signed-off-by: Arnaud Pouliquen 
> ---
>  drivers/remoteproc/stm32_rproc.c | 63 ++--
>  1 file changed, 60 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/remoteproc/stm32_rproc.c 
> b/drivers/remoteproc/stm32_rproc.c
> index 79c638936163..400a7a93b1c9 100644
> --- a/drivers/remoteproc/stm32_rproc.c
> +++ b/drivers/remoteproc/stm32_rproc.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -257,6 +258,19 @@ static int stm32_rproc_release(struct rproc *rproc)
>   return 0;
>  }
>  
> +static int stm32_rproc_tee_stop(struct rproc *rproc)
> +{
> + int err;
> +
> + stm32_rproc_request_shutdown(rproc);
> +
> + err = tee_rproc_stop(rproc);
> + if (err)
> + return err;
> +
> + return stm32_rproc_release(rproc);
> +}
> +
>  static int stm32_rproc_prepare(struct rproc *rproc)
>  {
>   struct device *dev = rproc->dev.parent;
> @@ -693,8 +707,20 @@ static const struct rproc_ops st_rproc_ops = {
>   .get_boot_addr  = rproc_elf_get_boot_addr,
>  };
>  
> +static const struct rproc_ops st_rproc_tee_ops = {
> + .prepare= stm32_rproc_prepare,
> + .start  = tee_rproc_start,
> + .stop   = stm32_rproc_tee_stop,
> + .kick   = stm32_rproc_kick,
> + .load   = tee_rproc_load_fw,
> + .parse_fw   = tee_rproc_parse_fw,
> + .find_loaded_rsc_table = tee_rproc_find_loaded_rsc_table,
> +
> +};
> +
>  static const struct of_device_id stm32_rproc_match[] = {
>   { .compatible = "st,stm32mp1-m4" },
> + { .compatible = "st,stm32mp1-m4-tee" },
>   {},
>  };
>  MODULE_DEVICE_TABLE(of, stm32_rproc_match);
> @@ -853,17 +879,42 @@ static int stm32_rproc_probe(struct platform_device 
> *pdev)
>   struct device *dev = &pdev->dev;
>   struct stm32_rproc *ddata;
>   struct device_node *np = dev->of_node;
> + struct tee_rproc *trproc = NULL;
>   struct rproc *rproc;
>   unsigned int state;
> + u32 proc_id;
>   int ret;
>  
>   ret = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(32));
>   if (ret)
>   return ret;
>  
> - rproc = devm_rproc_alloc(dev, np->name, &st_rproc_ops, NULL, 
> sizeof(*ddata));
> - if (!rproc)
> - return -ENOMEM;
> + if (of_device_is_compatible(np, "st,stm32mp1-m4-tee")) {
> + /*
> +  * Delegate the firmware management to the secure context.
> +  * The firmware loaded has to be signed.
> +  */
> + ret = of_property_read_u32(np, "st,proc-id", &proc_id);
> + if (ret) {
> + dev_err(dev, "failed to read st,rproc-id property\n");
> + return ret;
> + }
> +
> + rproc = devm_rproc_alloc(dev, np->name, &st_rproc_tee_ops, 
> NULL, sizeof(*ddata));
> + if (!rproc)
> + return -ENOMEM;
> +
> + trproc = tee_rproc_register(dev, rproc, proc_id);
> + if (IS_ERR(trproc)) {
> + dev_err_probe(dev, PTR_ERR(trproc),
> +   "signed firmware not supported by TEE\n");
> + return PTR_ERR(trproc);
> + }
> + } else {
> + rproc = devm_rproc_alloc(dev, np->name, &st_rproc_ops, NULL, 
> sizeof(*ddata));
> + if (!rproc)
> + return -ENOMEM;
> + }
>  
>   ddata = rproc->priv;
>  
> @@ -915,6 +966,9 @@ static int stm32_rproc_probe(struct platform_device *pdev)
>   dev_pm_clear_wake_irq(dev);
>   device_init_wakeup(dev, false);
>   }
> + if (trproc)

if (rproc->tee_interface)

I am done reviewing this set.

> + tee_rproc_unregister(trproc);
> +
>   return ret;
>  }
>  
> @@ -935,6 +989,9 @@ static void stm32_rproc_remove(struct platform_device 
> *pdev)
>   dev_pm_clear_wake_irq(dev);
>   device_init_wakeup(dev, false);
>   }
> + if (rproc->tee_interface)
> + tee_rproc_unregister(rproc->tee_interface);
> +
>  }
>  
>  static int stm32_rproc_suspend(struct device *dev)
> -- 
> 2.25.1
> 

Re: [PATCH v9 2/7] remoteproc: Add TEE support

[Mathieu Poirier]

On Fri, Aug 30, 2024 at 11:51:42AM +0200, Arnaud Pouliquen wrote:
> Add a remoteproc TEE (Trusted Execution Environment) driver
> that will be probed by the TEE bus. If the associated Trusted
> application is supported on secure part this driver offers a client
> interface to load a firmware by the secure part.
> This firmware could be authenticated by the secure trusted application.
> 
> Signed-off-by: Arnaud Pouliquen 
> ---
> Updates vs previous version:
> - add TA_RPROC_CMD_RELEASE_FW TEE command support to release firmware 
> resources,
> - add tee_rproc_release_fw() API that will be called by the remoteproc core,
> - release the firmware resources in case of error in tee_rproc_parse_fw() 
> function
> ---
>  drivers/remoteproc/Kconfig  |  10 +
>  drivers/remoteproc/Makefile |   1 +
>  drivers/remoteproc/remoteproc_tee.c | 486 
>  include/linux/remoteproc.h  |   4 +
>  include/linux/remoteproc_tee.h  | 109 +++
>  5 files changed, 610 insertions(+)
>  create mode 100644 drivers/remoteproc/remoteproc_tee.c
>  create mode 100644 include/linux/remoteproc_tee.h
> 
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index dda2ada215b7..93c3de7727bb 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -366,6 +366,16 @@ config XLNX_R5_REMOTEPROC
>  
> It's safe to say N if not interested in using RPU r5f cores.
>  
> +
> +config REMOTEPROC_TEE
> + tristate "Remoteproc support by a TEE application"
> + depends on OPTEE
> + help
> +   Support a remote processor with a TEE application. The Trusted
> +   Execution Context is responsible for loading the trusted firmware
> +   image and managing the remote processor's lifecycle.
> +   This can be either built-in or a loadable module.
> +
>  endif # REMOTEPROC
>  
>  endmenu
> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> index 91314a9b43ce..b4eb37177005 100644
> --- a/drivers/remoteproc/Makefile
> +++ b/drivers/remoteproc/Makefile
> @@ -36,6 +36,7 @@ obj-$(CONFIG_RCAR_REMOTEPROC)   += rcar_rproc.o
>  obj-$(CONFIG_ST_REMOTEPROC)  += st_remoteproc.o
>  obj-$(CONFIG_ST_SLIM_REMOTEPROC) += st_slim_rproc.o
>  obj-$(CONFIG_STM32_RPROC)+= stm32_rproc.o
> +obj-$(CONFIG_REMOTEPROC_TEE) += remoteproc_tee.o
>  obj-$(CONFIG_TI_K3_DSP_REMOTEPROC)   += ti_k3_dsp_remoteproc.o
>  obj-$(CONFIG_TI_K3_R5_REMOTEPROC)+= ti_k3_r5_remoteproc.o
>  obj-$(CONFIG_XLNX_R5_REMOTEPROC) += xlnx_r5_remoteproc.o
> diff --git a/drivers/remoteproc/remoteproc_tee.c 
> b/drivers/remoteproc/remoteproc_tee.c
> new file mode 100644
> index ..d4a10c99f6e1
> --- /dev/null
> +++ b/drivers/remoteproc/remoteproc_tee.c
> @@ -0,0 +1,486 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) STMicroelectronics 2024
> + * Author: Arnaud Pouliquen 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define MAX_TEE_PARAM_ARRY_MEMBER4
> +
> +/*
> + * Authentication of the firmware and load in the remote processor memory
> + *
> + * [in]  params[0].value.a:  unique 32bit identifier of the remote processor
> + * [in]   params[1].memref:  buffer containing the image of the 
> buffer
> + */
> +#define TA_RPROC_FW_CMD_LOAD_FW  1
> +
> +/*
> + * Start the remote processor
> + *
> + * [in]  params[0].value.a:  unique 32bit identifier of the remote processor
> + */
> +#define TA_RPROC_FW_CMD_START_FW 2
> +
> +/*
> + * Stop the remote processor
> + *
> + * [in]  params[0].value.a:  unique 32bit identifier of the remote processor
> + */
> +#define TA_RPROC_FW_CMD_STOP_FW  3
> +
> +/*
> + * Return the address of the resource table, or 0 if not found
> + * No check is done to verify that the address returned is accessible by
> + * the non secure context. If the resource table is loaded in a protected
> + * memory the access by the non secure context will lead to a data abort.
> + *
> + * [in]  params[0].value.a:  unique 32bit identifier of the remote processor
> + * [out]  params[1].value.a: 32bit LSB resource table memory address
> + * [out]  params[1].value.b: 32bit MSB resource table memory address
> + * [out]  params[2].value.a: 32bit LSB resource table memory size
> + * [out]  params[2].value.b: 32bit MSB resource table memory size
> + */
> +#define TA_RPROC_FW_CMD_GET_RSC_TABLE4
> +
> +/*
> + * Return the address of the core dump
> + *
> + * [in]  params[0].value.a:  unique 32bit identifier of the remote processor
> + * [out] params[1].memref:   address of the core dump image if exist,
> + *   else return Null
> + */
> +#define TA_RPROC_FW_CMD_GET_COREDUMP 5
> +
> +/*
> + * Release remote processor firmware images and associated resources.
> + * This command should be used in case an error occurs between the loading of
> + * the firmware im

Re: [PATCH v1 0/5] Add Microchip IPC mailbox and remoteproc support

[Mathieu Poirier]

Hi Valentina,

On Thu, 12 Sept 2024 at 10:48, Valentina Fernandez
 wrote:
>
> Hello all,
>
> This series adds support for the Microchip Inter-Processor Communication
> (IPC) mailbox controller, as well as an IPC remoteproc platform driver.
>
> Microchip's family of RISC-V SoCs typically has one or more clusters
> that can be configured to run in Asymmetric Multi-Processing (AMP) mode.
>
> The Microchip IPC is used to send messages between processors using
> an interrupt signaling mechanism. The driver uses the RISC-V Supervisor
> Binary Interface (SBI) to communicate with software running in machine
> mode (M-mode) to access the IPC hardware block.
>
> Additional details on the Microchip vendor extension and the IPC
> function IDs described in the driver can be found in the following
> documentation:
>
> https://github.com/linux4microchip/microchip-sbi-ecall-extension
>
> The IPC remoteproc platform driver allows for starting and stopping
> firmware on the remote cluster(s) and facilitates RPMsg communication.
> The remoteproc attach/detach operations are also supported for use cases
> where the firmware is loaded by the Hart Software Services
> (zero-stage bootloader) before Linux boots.
>
> Error Recovery and Power Management features are not currently
> supported in the remoteproc platform driver.
>
> The PIC64GX MPU has a Mi-V IHC block, this will be added to the PIC64GX
> dts after the initial upstreaming:
>
> https://patchwork.kernel.org/project/linux-riscv/patch/20240725121609.13101-18-pierre-henry.mous...@microchip.com/
>
> Thanks,
> Valentina
>
> Valentina Fernandez (5):
>   riscv: asm: vendorid_list: Add Microchip Technology to the vendor list
>   dt-bindings: mailbox: add binding for Microchip IPC mailbox driver
>   mailbox: add Microchip IPC support
>   dt-bindings: remoteproc: add binding for Microchip IPC remoteproc
>   remoteproc: add support for Microchip IPC remoteproc platform driver
>
>  .../bindings/mailbox/microchip,sbi-ipc.yaml   | 115 
>  .../remoteproc/microchip,ipc-remoteproc.yaml  |  84 +++
>  arch/riscv/include/asm/vendorid_list.h|   1 +
>  drivers/mailbox/Kconfig   |  12 +
>  drivers/mailbox/Makefile  |   2 +
>  drivers/mailbox/mailbox-mchp-ipc-sbi.c| 539 ++
>  drivers/remoteproc/Kconfig|  12 +
>  drivers/remoteproc/Makefile   |   1 +
>  drivers/remoteproc/mchp_ipc_remoteproc.c  | 461 +++
>  include/linux/mailbox/mchp-ipc.h  |  23 +
>  10 files changed, 1250 insertions(+)

It might be easier to split this patchset in two and proceed
incrementally, i.e upstream the mailbox driver first and then the
remoteproc part.

Regards,
Mathieu

>  create mode 100644 
> Documentation/devicetree/bindings/mailbox/microchip,sbi-ipc.yaml
>  create mode 100644 
> Documentation/devicetree/bindings/remoteproc/microchip,ipc-remoteproc.yaml
>  create mode 100644 drivers/mailbox/mailbox-mchp-ipc-sbi.c
>  create mode 100644 drivers/remoteproc/mchp_ipc_remoteproc.c
>  create mode 100644 include/linux/mailbox/mchp-ipc.h
>
> --
> 2.34.1
>

Re: [PATCH v9 6/7] remoteproc: stm32: Create sub-functions to request shutdown and release

[Mathieu Poirier]

On Fri, Aug 30, 2024 at 11:51:46AM +0200, Arnaud Pouliquen wrote:
> To prepare for the support of TEE remoteproc, create sub-functions
> that can be used in both cases, with and without remoteproc TEE support.
> 
> Signed-off-by: Arnaud Pouliquen 
> ---
>  drivers/remoteproc/stm32_rproc.c | 84 +++-
>  1 file changed, 51 insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/remoteproc/stm32_rproc.c 
> b/drivers/remoteproc/stm32_rproc.c
> index 8c7f7950b80e..79c638936163 100644
> --- a/drivers/remoteproc/stm32_rproc.c
> +++ b/drivers/remoteproc/stm32_rproc.c
> @@ -209,6 +209,54 @@ static int stm32_rproc_mbox_idx(struct rproc *rproc, 
> const unsigned char *name)
>   return -EINVAL;
>  }
>  
> +static void stm32_rproc_request_shutdown(struct rproc *rproc)
> +{
> + struct stm32_rproc *ddata = rproc->priv;
> + int err, dummy_data, idx;
> +
> + /* Request shutdown of the remote processor */
> + if (rproc->state != RPROC_OFFLINE && rproc->state != RPROC_CRASHED) {
> + idx = stm32_rproc_mbox_idx(rproc, STM32_MBX_SHUTDOWN);
> + if (idx >= 0 && ddata->mb[idx].chan) {
> + /* A dummy data is sent to allow to block on transmit. 
> */
> + err = mbox_send_message(ddata->mb[idx].chan,
> + &dummy_data);

When refactoring functions, please do not change the inner code.  Here
@dummy_data was introduced.  Making changes, even small ones, makes it really
hard to review your work.  I'm pretty sure we talked about that before.

> + if (err < 0)
> + dev_warn(&rproc->dev, "warning: remote FW 
> shutdown without ack\n");
> + }
> + }
> +}
> +
> +static int stm32_rproc_release(struct rproc *rproc)
> +{
> + struct stm32_rproc *ddata = rproc->priv;
> + unsigned int err = 0;
> +
> + /* To allow platform Standby power mode, set remote proc Deep Sleep. */
> + if (ddata->pdds.map) {
> + err = regmap_update_bits(ddata->pdds.map, ddata->pdds.reg,
> +  ddata->pdds.mask, 1);
> + if (err) {
> + dev_err(&rproc->dev, "failed to set pdds\n");
> + return err;
> + }
> + }
> +
> + /* Update coprocessor state to OFF if available. */
> + if (ddata->m4_state.map) {
> + err = regmap_update_bits(ddata->m4_state.map,
> +  ddata->m4_state.reg,
> +  ddata->m4_state.mask,
> +  M4_STATE_OFF);
> + if (err) {
> + dev_err(&rproc->dev, "failed to set copro state\n");
> + return err;
> + }
> + }
> +
> + return 0;
> +}
> +
>  static int stm32_rproc_prepare(struct rproc *rproc)
>  {
>   struct device *dev = rproc->dev.parent;
> @@ -519,17 +567,9 @@ static int stm32_rproc_detach(struct rproc *rproc)
>  static int stm32_rproc_stop(struct rproc *rproc)
>  {
>   struct stm32_rproc *ddata = rproc->priv;
> - int err, idx;
> + int err;
>  
> - /* request shutdown of the remote processor */
> - if (rproc->state != RPROC_OFFLINE && rproc->state != RPROC_CRASHED) {
> - idx = stm32_rproc_mbox_idx(rproc, STM32_MBX_SHUTDOWN);
> - if (idx >= 0 && ddata->mb[idx].chan) {
> - err = mbox_send_message(ddata->mb[idx].chan, "detach");
> - if (err < 0)
> - dev_warn(&rproc->dev, "warning: remote FW 
> shutdown without ack\n");
> - }
> - }
> + stm32_rproc_request_shutdown(rproc);
>  
>   err = stm32_rproc_set_hold_boot(rproc, true);
>   if (err)
> @@ -541,29 +581,7 @@ static int stm32_rproc_stop(struct rproc *rproc)
>   return err;
>   }
>  
> - /* to allow platform Standby power mode, set remote proc Deep Sleep */
> - if (ddata->pdds.map) {
> - err = regmap_update_bits(ddata->pdds.map, ddata->pdds.reg,
> -  ddata->pdds.mask, 1);
> - if (err) {
> - dev_err(&rproc->dev, "failed to set pdds\n");
> - return err;
> - }
> - }
> -
> - /* update coprocessor state to OFF if available */
> - if (ddata->m4_state.map) {
> - err = regmap_update_bits(ddata->m4_state.map,
> -  ddata->m4_state.reg,
> -  ddata->m4_state.mask,
> -  M4_STATE_OFF);
> - if (err) {
> - dev_err(&rproc->dev, "failed to set copro state\n");
> - return err;
> - }
> - }
> -
> - return 0;
> + return stm32_rproc_release(rproc);
>  }
>  
>  static void stm32_rproc_kick(struct rproc *rproc, int vqid)
> -- 
> 2.25.

Re: [PATCH v9 4/7] remoteproc: core: Add TEE interface support for firmware release

[Mathieu Poirier]

On Fri, Aug 30, 2024 at 11:51:44AM +0200, Arnaud Pouliquen wrote:
> Add support for releasing remote processor firmware through
> the Trusted Execution Environment (TEE) interface.
> 
> The tee_rproc_release_fw() function is called in the following cases:
> 
> - An error occurs in rproc_start() between the loading of the segments and
>   the start of the remote processor.
> - When rproc_release_fw is called on error or after stopping the remote
>   processor.
> 
> Signed-off-by: Arnaud Pouliquen 
> ---
>  drivers/remoteproc/remoteproc_core.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/remoteproc/remoteproc_core.c 
> b/drivers/remoteproc/remoteproc_core.c
> index 7694817f25d4..32052dedc149 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -29,6 +29,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1258,6 +1259,9 @@ static int rproc_alloc_registered_carveouts(struct 
> rproc *rproc)
>  
>  static void rproc_release_fw(struct rproc *rproc)
>  {
> + if (rproc->state == RPROC_OFFLINE && rproc->tee_interface)
> + tee_rproc_release_fw(rproc);

Function tee_rproc_release_fw() returns a value that is ignored.  I don't know
how it passes the Sparse checker but I already see patches coming in my Inbox to
deal with that.  In this case there is nothing else to do if there is an error
releasing the firware.  As such I would put a (void) in front and add a comment
about the return value being ignore on purpose.

> +
>   /* Free the copy of the resource table */
>   kfree(rproc->cached_table);
>   rproc->cached_table = NULL;
> @@ -1348,7 +1352,7 @@ static int rproc_start(struct rproc *rproc, const 
> struct firmware *fw)
>   if (ret) {
>   dev_err(dev, "failed to prepare subdevices for %s: %d\n",
>   rproc->name, ret);
> - goto reset_table_ptr;
> + goto release_fw;
>   }
>  
>   /* power up the remote processor */
> @@ -1376,7 +1380,9 @@ static int rproc_start(struct rproc *rproc, const 
> struct firmware *fw)
>   rproc->ops->stop(rproc);
>  unprepare_subdevices:
>   rproc_unprepare_subdevices(rproc);
> -reset_table_ptr:
> +release_fw:
> + if (rproc->tee_interface)
> + tee_rproc_release_fw(rproc);

Same here.

>   rproc->table_ptr = rproc->cached_table;
>  
>   return ret;
> -- 
> 2.25.1
> 

Re: [PATCH v9 4/7] remoteproc: core: Add TEE interface support for firmware release

[Mathieu Poirier]

On Fri, Aug 30, 2024 at 11:51:44AM +0200, Arnaud Pouliquen wrote:
> Add support for releasing remote processor firmware through
> the Trusted Execution Environment (TEE) interface.
> 
> The tee_rproc_release_fw() function is called in the following cases:
> 
> - An error occurs in rproc_start() between the loading of the segments and
>   the start of the remote processor.
> - When rproc_release_fw is called on error or after stopping the remote
>   processor.
> 
> Signed-off-by: Arnaud Pouliquen 
> ---
>  drivers/remoteproc/remoteproc_core.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/remoteproc/remoteproc_core.c 
> b/drivers/remoteproc/remoteproc_core.c
> index 7694817f25d4..32052dedc149 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -29,6 +29,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1258,6 +1259,9 @@ static int rproc_alloc_registered_carveouts(struct 
> rproc *rproc)
>  
>  static void rproc_release_fw(struct rproc *rproc)
>  {
> + if (rproc->state == RPROC_OFFLINE && rproc->tee_interface)
> + tee_rproc_release_fw(rproc);
> +

If I understand correctly, the first condition is there because the
attach/detach scenario does not yet support management by the TEE.  I would
simply move the check to tee_rproc_release_fw() with a comment to that effect.

>   /* Free the copy of the resource table */
>   kfree(rproc->cached_table);
>   rproc->cached_table = NULL;
> @@ -1348,7 +1352,7 @@ static int rproc_start(struct rproc *rproc, const 
> struct firmware *fw)
>   if (ret) {
>   dev_err(dev, "failed to prepare subdevices for %s: %d\n",
>   rproc->name, ret);
> - goto reset_table_ptr;
> + goto release_fw;
>   }
>  
>   /* power up the remote processor */
> @@ -1376,7 +1380,9 @@ static int rproc_start(struct rproc *rproc, const 
> struct firmware *fw)
>   rproc->ops->stop(rproc);
>  unprepare_subdevices:
>   rproc_unprepare_subdevices(rproc);
> -reset_table_ptr:
> +release_fw:

I would have kept the old label.

> + if (rproc->tee_interface)
> + tee_rproc_release_fw(rproc);
>   rproc->table_ptr = rproc->cached_table;
>  
>   return ret;
> -- 
> 2.25.1
> 

Re: [PATCH v9 2/7] remoteproc: Add TEE support

[Mathieu Poirier]

On Fri, Aug 30, 2024 at 11:51:42AM +0200, Arnaud Pouliquen wrote:
> Add a remoteproc TEE (Trusted Execution Environment) driver
> that will be probed by the TEE bus. If the associated Trusted
> application is supported on secure part this driver offers a client
> interface to load a firmware by the secure part.
> This firmware could be authenticated by the secure trusted application.
> 
> Signed-off-by: Arnaud Pouliquen 
> ---
> Updates vs previous version:
> - add TA_RPROC_CMD_RELEASE_FW TEE command support to release firmware 
> resources,
> - add tee_rproc_release_fw() API that will be called by the remoteproc core,
> - release the firmware resources in case of error in tee_rproc_parse_fw() 
> function
> ---
>  drivers/remoteproc/Kconfig  |  10 +
>  drivers/remoteproc/Makefile |   1 +
>  drivers/remoteproc/remoteproc_tee.c | 486 
>  include/linux/remoteproc.h  |   4 +
>  include/linux/remoteproc_tee.h  | 109 +++
>  5 files changed, 610 insertions(+)
>  create mode 100644 drivers/remoteproc/remoteproc_tee.c
>  create mode 100644 include/linux/remoteproc_tee.h
> 
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index dda2ada215b7..93c3de7727bb 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -366,6 +366,16 @@ config XLNX_R5_REMOTEPROC
>  
> It's safe to say N if not interested in using RPU r5f cores.
>  
> +
> +config REMOTEPROC_TEE
> + tristate "Remoteproc support by a TEE application"
> + depends on OPTEE
> + help
> +   Support a remote processor with a TEE application. The Trusted
> +   Execution Context is responsible for loading the trusted firmware
> +   image and managing the remote processor's lifecycle.
> +   This can be either built-in or a loadable module.
> +
>  endif # REMOTEPROC
>  
>  endmenu
> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> index 91314a9b43ce..b4eb37177005 100644
> --- a/drivers/remoteproc/Makefile
> +++ b/drivers/remoteproc/Makefile
> @@ -36,6 +36,7 @@ obj-$(CONFIG_RCAR_REMOTEPROC)   += rcar_rproc.o
>  obj-$(CONFIG_ST_REMOTEPROC)  += st_remoteproc.o
>  obj-$(CONFIG_ST_SLIM_REMOTEPROC) += st_slim_rproc.o
>  obj-$(CONFIG_STM32_RPROC)+= stm32_rproc.o
> +obj-$(CONFIG_REMOTEPROC_TEE) += remoteproc_tee.o

Please move this up to be with the other core remoteproc files, just after
CONFIG_REMOTEPROC_CDEV should be fine.

>  obj-$(CONFIG_TI_K3_DSP_REMOTEPROC)   += ti_k3_dsp_remoteproc.o
>  obj-$(CONFIG_TI_K3_R5_REMOTEPROC)+= ti_k3_r5_remoteproc.o
>  obj-$(CONFIG_XLNX_R5_REMOTEPROC) += xlnx_r5_remoteproc.o
> diff --git a/drivers/remoteproc/remoteproc_tee.c 
> b/drivers/remoteproc/remoteproc_tee.c
> new file mode 100644
> index ..d4a10c99f6e1
> --- /dev/null
> +++ b/drivers/remoteproc/remoteproc_tee.c
> @@ -0,0 +1,486 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) STMicroelectronics 2024
> + * Author: Arnaud Pouliquen 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define MAX_TEE_PARAM_ARRY_MEMBER4
> +
> +/*
> + * Authentication of the firmware and load in the remote processor memory
> + *
> + * [in]  params[0].value.a:  unique 32bit identifier of the remote processor
> + * [in]   params[1].memref:  buffer containing the image of the 
> buffer
> + */
> +#define TA_RPROC_FW_CMD_LOAD_FW  1
> +
> +/*
> + * Start the remote processor
> + *
> + * [in]  params[0].value.a:  unique 32bit identifier of the remote processor
> + */
> +#define TA_RPROC_FW_CMD_START_FW 2
> +
> +/*
> + * Stop the remote processor
> + *
> + * [in]  params[0].value.a:  unique 32bit identifier of the remote processor
> + */
> +#define TA_RPROC_FW_CMD_STOP_FW  3
> +
> +/*
> + * Return the address of the resource table, or 0 if not found
> + * No check is done to verify that the address returned is accessible by
> + * the non secure context. If the resource table is loaded in a protected
> + * memory the access by the non secure context will lead to a data abort.
> + *
> + * [in]  params[0].value.a:  unique 32bit identifier of the remote processor
> + * [out]  params[1].value.a: 32bit LSB resource table memory address
> + * [out]  params[1].value.b: 32bit MSB resource table memory address
> + * [out]  params[2].value.a: 32bit LSB resource table memory size
> + * [out]  params[2].value.b: 32bit MSB resource table memory size
> + */
> +#define TA_RPROC_FW_CMD_GET_RSC_TABLE4
> +
> +/*
> + * Return the address of the core dump
> + *
> + * [in]  params[0].value.a:  unique 32bit identifier of the remote processor
> + * [out] params[1].memref:   address of the core dump image if exist,
> + *   else return Null
> + */
> +#define TA_RPROC_FW_CMD_GET_COREDUMP 5
> +
> +/*
> + * Release remote processor firmware images and associat

Re: [PATCH v9 3/7] remoteproc: core: Refactor resource table cleanup into rproc_release_fw

[Mathieu Poirier]

On Fri, Aug 30, 2024 at 11:51:43AM +0200, Arnaud Pouliquen wrote:
> This patch centralizing the cleanup of the resource table into a new
> helper function rproc_release_fw().
> 

Sure, but you did not explain _why_ the change is needed.

> Suggested-by: Mathieu Poirier 
> Signed-off-by: Arnaud Pouliquen 
> ---
>  drivers/remoteproc/remoteproc_core.c | 21 ++---
>  1 file changed, 10 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/remoteproc/remoteproc_core.c 
> b/drivers/remoteproc/remoteproc_core.c
> index ace11ea17097..7694817f25d4 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -1256,6 +1256,13 @@ static int rproc_alloc_registered_carveouts(struct 
> rproc *rproc)
>   return 0;
>  }
>  
> +static void rproc_release_fw(struct rproc *rproc)
> +{
> + /* Free the copy of the resource table */
> + kfree(rproc->cached_table);
> + rproc->cached_table = NULL;
> + rproc->table_ptr = NULL;
> +}
>  
>  /**
>   * rproc_resource_cleanup() - clean up and free all acquired resources
> @@ -1485,9 +1492,7 @@ static int rproc_fw_boot(struct rproc *rproc, const 
> struct firmware *fw)
>  
>  clean_up_resources:
>   rproc_resource_cleanup(rproc);
> - kfree(rproc->cached_table);
> - rproc->cached_table = NULL;
> - rproc->table_ptr = NULL;
> + rproc_release_fw(rproc);
>  unprepare_rproc:
>   /* release HW resources if needed */
>   rproc_unprepare_device(rproc);
> @@ -2067,10 +2072,7 @@ int rproc_shutdown(struct rproc *rproc)
>  
>   rproc_disable_iommu(rproc);
>  
> - /* Free the copy of the resource table */
> - kfree(rproc->cached_table);
> - rproc->cached_table = NULL;
> - rproc->table_ptr = NULL;
> + rproc_release_fw(rproc);
>  out:
>   mutex_unlock(&rproc->lock);
>   return ret;
> @@ -2133,10 +2135,7 @@ int rproc_detach(struct rproc *rproc)
>  
>   rproc_disable_iommu(rproc);
>  
> - /* Free the copy of the resource table */
> - kfree(rproc->cached_table);
> - rproc->cached_table = NULL;
> - rproc->table_ptr = NULL;
> + rproc_release_fw(rproc);
>  out:
>   mutex_unlock(&rproc->lock);
>   return ret;
> -- 
> 2.25.1
> 

Re: [PATCH v9 2/7] remoteproc: Add TEE support

[Mathieu Poirier]

On Fri, Aug 30, 2024 at 11:51:42AM +0200, Arnaud Pouliquen wrote:
> Add a remoteproc TEE (Trusted Execution Environment) driver
> that will be probed by the TEE bus. If the associated Trusted
> application is supported on secure part this driver offers a client
> interface to load a firmware by the secure part.
> This firmware could be authenticated by the secure trusted application.
> 
> Signed-off-by: Arnaud Pouliquen 
> ---
> Updates vs previous version:
> - add TA_RPROC_CMD_RELEASE_FW TEE command support to release firmware 
> resources,
> - add tee_rproc_release_fw() API that will be called by the remoteproc core,
> - release the firmware resources in case of error in tee_rproc_parse_fw() 
> function
> ---
>  drivers/remoteproc/Kconfig  |  10 +
>  drivers/remoteproc/Makefile |   1 +
>  drivers/remoteproc/remoteproc_tee.c | 486 
>  include/linux/remoteproc.h  |   4 +
>  include/linux/remoteproc_tee.h  | 109 +++
>  5 files changed, 610 insertions(+)
>  create mode 100644 drivers/remoteproc/remoteproc_tee.c
>  create mode 100644 include/linux/remoteproc_tee.h
> 
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index dda2ada215b7..93c3de7727bb 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -366,6 +366,16 @@ config XLNX_R5_REMOTEPROC
>  
> It's safe to say N if not interested in using RPU r5f cores.
>  
> +
> +config REMOTEPROC_TEE
> + tristate "Remoteproc support by a TEE application"
> + depends on OPTEE
> + help
> +   Support a remote processor with a TEE application. The Trusted
> +   Execution Context is responsible for loading the trusted firmware
> +   image and managing the remote processor's lifecycle.
> +   This can be either built-in or a loadable module.
> +
>  endif # REMOTEPROC
>  
>  endmenu
> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> index 91314a9b43ce..b4eb37177005 100644
> --- a/drivers/remoteproc/Makefile
> +++ b/drivers/remoteproc/Makefile
> @@ -36,6 +36,7 @@ obj-$(CONFIG_RCAR_REMOTEPROC)   += rcar_rproc.o
>  obj-$(CONFIG_ST_REMOTEPROC)  += st_remoteproc.o
>  obj-$(CONFIG_ST_SLIM_REMOTEPROC) += st_slim_rproc.o
>  obj-$(CONFIG_STM32_RPROC)+= stm32_rproc.o
> +obj-$(CONFIG_REMOTEPROC_TEE) += remoteproc_tee.o
>  obj-$(CONFIG_TI_K3_DSP_REMOTEPROC)   += ti_k3_dsp_remoteproc.o
>  obj-$(CONFIG_TI_K3_R5_REMOTEPROC)+= ti_k3_r5_remoteproc.o
>  obj-$(CONFIG_XLNX_R5_REMOTEPROC) += xlnx_r5_remoteproc.o
> diff --git a/drivers/remoteproc/remoteproc_tee.c 
> b/drivers/remoteproc/remoteproc_tee.c
> new file mode 100644
> index ..d4a10c99f6e1
> --- /dev/null
> +++ b/drivers/remoteproc/remoteproc_tee.c
> @@ -0,0 +1,486 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) STMicroelectronics 2024
> + * Author: Arnaud Pouliquen 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define MAX_TEE_PARAM_ARRY_MEMBER4

s/MAX_TEE_PARAM_ARRY_MEMBER/MAX_TEE_PARAM_ARRAY_MEMBER

Comments for this patchset will be staggered over several days.  I will let you
know when I am done.

> +
> +/*
> + * Authentication of the firmware and load in the remote processor memory
> + *
> + * [in]  params[0].value.a:  unique 32bit identifier of the remote processor
> + * [in]   params[1].memref:  buffer containing the image of the 
> buffer
> + */
> +#define TA_RPROC_FW_CMD_LOAD_FW  1
> +
> +/*
> + * Start the remote processor
> + *
> + * [in]  params[0].value.a:  unique 32bit identifier of the remote processor
> + */
> +#define TA_RPROC_FW_CMD_START_FW 2
> +
> +/*
> + * Stop the remote processor
> + *
> + * [in]  params[0].value.a:  unique 32bit identifier of the remote processor
> + */
> +#define TA_RPROC_FW_CMD_STOP_FW  3
> +
> +/*
> + * Return the address of the resource table, or 0 if not found
> + * No check is done to verify that the address returned is accessible by
> + * the non secure context. If the resource table is loaded in a protected
> + * memory the access by the non secure context will lead to a data abort.
> + *
> + * [in]  params[0].value.a:  unique 32bit identifier of the remote processor
> + * [out]  params[1].value.a: 32bit LSB resource table memory address
> + * [out]  params[1].value.b: 32bit MSB resource table memory address
> + * [out]  params[2].value.a: 32bit LSB resource table memory size
> + * [out]  params[2].value.b: 32bit MSB resource table memory size
> + */
> +#define TA_RPROC_FW_CMD_GET_RSC_TABLE4
> +
> +/*
> + * Return the address of the core dump
> + *
> + * [in]  params[0].value.a:  unique 32bit identifier of the remote processor
> + * [out] params[1].memref:   address of the core dump image if exist,
> + *   else return Null
> + */
> +#define TA_RPROC_FW_CMD_GET_COREDUMP 5
> +
> +/*
> + * Release re

Re: [PATCH v2] remoteproc: k3-dsp: Fix an error handling path in k3_dsp_rproc_probe()

[Mathieu Poirier]

On Sat, Sep 07, 2024 at 08:33:36AM +0200, Christophe JAILLET wrote:
> If an error occurs after the k3_dsp_rproc_request_mbox() call,
> mbox_free_channel() must be called, as already done in the remove function.
> 
> Instead of adding an error handling path in the probe and changing all
> error handling in the function, add a new devm_add_action_or_reset() and
> simplify the .remove() function.
> 
> Fixes: ea1d6fb5b571 ("remoteproc: k3-dsp: Acquire mailbox handle during probe 
> routine")
> Signed-off-by: Christophe JAILLET 
> Reviewed-by: Andrew Davis 
> ---
> Compile tested only
> 
> Change in v2:
>   - fix the subject (cut'n'paste issue)   [Andrew Davis]
>   - add R-b tag
>   
> v1: 
> https://lore.kernel.org/all/9485e127a00419c76cf13dbccf4874af395ef6ba.1725653543.git.christophe.jail...@wanadoo.fr/
> ---
>  drivers/remoteproc/ti_k3_dsp_remoteproc.c | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/remoteproc/ti_k3_dsp_remoteproc.c 
> b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
> index 8be3f631c192..f29780de37a5 100644
> --- a/drivers/remoteproc/ti_k3_dsp_remoteproc.c
> +++ b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
> @@ -610,6 +610,13 @@ static void k3_dsp_release_tsp(void *data)
>   ti_sci_proc_release(tsp);
>  }
>  
> +static void k3_dsp_free_channel(void *data)
> +{
> + struct k3_dsp_rproc *kproc = data;

How did the struct rproc from devm_add_action_or_reset() got turned into a
struct k3_dsp_rproc?

> +
> + mbox_free_channel(kproc->mbox);
> +}
> +
>  static int k3_dsp_rproc_probe(struct platform_device *pdev)
>  {
>   struct device *dev = &pdev->dev;
> @@ -649,6 +656,10 @@ static int k3_dsp_rproc_probe(struct platform_device 
> *pdev)
>   if (ret)
>   return ret;
>  
> + ret = devm_add_action_or_reset(dev, k3_dsp_free_channel, rproc);
> + if (ret)
> + return ret;
> +
>   kproc->ti_sci = devm_ti_sci_get_by_phandle(dev, "ti,sci");
>   if (IS_ERR(kproc->ti_sci))
>   return dev_err_probe(dev, PTR_ERR(kproc->ti_sci),
> @@ -741,8 +752,6 @@ static void k3_dsp_rproc_remove(struct platform_device 
> *pdev)
>   if (ret)
>   dev_err(dev, "failed to detach proc (%pe)\n", 
> ERR_PTR(ret));
>   }
> -
> - mbox_free_channel(kproc->mbox);
>  }
>  
>  static const struct k3_dsp_mem_data c66_mems[] = {
> -- 
> 2.46.0
> 

Re: [PATCH] mailbox, remoteproc: omap2+: fix compile testing

[Mathieu Poirier]

On Mon, Sep 09, 2024 at 08:38:09PM +, Arnd Bergmann wrote:
> From: Arnd Bergmann 
> 
> Selecting CONFIG_OMAP2PLUS_MBOX while compile testing
> causes a build failure:
> 
> WARNING: unmet direct dependencies detected for OMAP2PLUS_MBOX
>   Depends on [n]: MAILBOX [=y] && (ARCH_OMAP2PLUS || ARCH_K3)
>   Selected by [m]:
>   - TI_K3_M4_REMOTEPROC [=m] && REMOTEPROC [=y] && (ARCH_K3 || COMPILE_TEST 
> [=y])
> 
> Using 'select' to force-enable another subsystem is generally
> a mistake and causes problems such as this one, so change the
> three drivers that link against this driver to use 'depends on'
> instead, and ensure the driver itself can be compile tested
> regardless of the platform.
> 
> When compile-testing without CONFIG_TI_SCI_PROTOCOL=m, there
> is a chance for a link failure, so add a careful dependency
> on that.
> 
> arm-linux-gnueabi-ld: drivers/remoteproc/ti_k3_m4_remoteproc.o: in function 
> `k3_m4_rproc_probe':
> ti_k3_m4_remoteproc.c:(.text.k3_m4_rproc_probe+0x76): undefined reference to 
> `devm_ti_sci_get_by_phandle'
> 
> Fixes: ebcf9008a895 ("remoteproc: k3-m4: Add a remoteproc driver for M4F 
> subsystem")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/mailbox/Kconfig    |  2 +-
>  drivers/mailbox/omap-mailbox.c |  2 +-
>  drivers/remoteproc/Kconfig | 10 --

For the remoteproc part:

Reviewed-by: Mathieu Poirier 

>  3 files changed, 6 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
> index 4eed97295927..ecaf78beb934 100644
> --- a/drivers/mailbox/Kconfig
> +++ b/drivers/mailbox/Kconfig
> @@ -73,7 +73,7 @@ config ARMADA_37XX_RWTM_MBOX
>  
>  config OMAP2PLUS_MBOX
>   tristate "OMAP2+ Mailbox framework support"
> - depends on ARCH_OMAP2PLUS || ARCH_K3
> + depends on ARCH_OMAP2PLUS || ARCH_K3 || COMPILE_TEST
>   help
> Mailbox implementation for OMAP family chips with hardware for
> interprocessor communication involving DSP, IVA1.0 and IVA2 in
> diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
> index 7a87424657a1..6797770474a5 100644
> --- a/drivers/mailbox/omap-mailbox.c
> +++ b/drivers/mailbox/omap-mailbox.c
> @@ -603,7 +603,7 @@ static struct platform_driver omap_mbox_driver = {
>   .driver = {
>   .name = "omap-mailbox",
>   .pm = &omap_mbox_pm_ops,
> - .of_match_table = of_match_ptr(omap_mailbox_of_match),
> + .of_match_table = omap_mailbox_of_match,
>   },
>  };
>  module_platform_driver(omap_mbox_driver);
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index 0f0862e20a93..62f8548fb46a 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -330,8 +330,7 @@ config STM32_RPROC
>  config TI_K3_DSP_REMOTEPROC
>   tristate "TI K3 DSP remoteproc support"
>   depends on ARCH_K3
> - select MAILBOX
> - select OMAP2PLUS_MBOX
> + depends on OMAP2PLUS_MBOX
>   help
> Say m here to support TI's C66x and C71x DSP remote processor
> subsystems on various TI K3 family of SoCs through the remote
> @@ -343,8 +342,8 @@ config TI_K3_DSP_REMOTEPROC
>  config TI_K3_M4_REMOTEPROC
>   tristate "TI K3 M4 remoteproc support"
>   depends on ARCH_K3 || COMPILE_TEST
> - select MAILBOX
> - select OMAP2PLUS_MBOX
> + depends on TI_SCI_PROTOCOL || (COMPILE_TEST && TI_SCI_PROTOCOL=n)
> + depends on OMAP2PLUS_MBOX
>   help
> Say m here to support TI's M4 remote processor subsystems
> on various TI K3 family of SoCs through the remote processor
> @@ -356,8 +355,7 @@ config TI_K3_M4_REMOTEPROC
>  config TI_K3_R5_REMOTEPROC
>   tristate "TI K3 R5 remoteproc support"
>   depends on ARCH_K3
> - select MAILBOX
> - select OMAP2PLUS_MBOX
> + depends on OMAP2PLUS_MBOX
>   help
> Say m here to support TI's R5F remote processor subsystems
> on various TI K3 family of SoCs through the remote processor
> -- 
> 2.39.2
> 

Re: [PATCH] remoteproc: k3-r5: Decouple firmware booting from probe routine

[Mathieu Poirier]

On Fri, Sep 06, 2024 at 03:10:45PM +0530, Beleswar Padhi wrote:
> The current implementation of the waiting mechanism in probe() waits for
> the 'released_from_reset' flag to be set which is done in
> k3_r5_rproc_prepare() as part of rproc_fw_boot(). This causes unexpected

If you are looking at rproc-next, @released_from_reset is set in
k3_r5_rproc_start().  Moreover, the waiting mechanic happens in
k3_r5_cluster_rproc_init(), which makes reading your changelog highly confusing.

> failures in cases where the firmware is unavailable at boot time,
> resulting in probe failure and removal of the remoteproc handles in the
> sysfs paths.
> 
> To address this, the waiting mechanism is refactored out of the probe
> routine into the appropriate k3_r5_rproc_prepare/unprepare() and
> k3_r5_rproc_start/stop() functions. This allows the probe routine to
> complete without depending on firmware booting, while still maintaining
> the required power-synchronization between cores.
> 
> Fixes: 61f6f68447ab ("remoteproc: k3-r5: Wait for core0 power-up before 
> powering up core1")
> Signed-off-by: Beleswar Padhi 
> ---
> Posted this as a Fix as this was breaking usecases where we wanted to load a
> firmware by writing to sysfs handles in userspace.
> 
>  drivers/remoteproc/ti_k3_r5_remoteproc.c | 170 ---
>  1 file changed, 118 insertions(+), 52 deletions(-)
> 
> diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c 
> b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> index 747ee467da88..df8f124f4248 100644
> --- a/drivers/remoteproc/ti_k3_r5_remoteproc.c
> +++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> @@ -131,6 +131,7 @@ struct k3_r5_cluster {
>   * @btcm_enable: flag to control BTCM enablement
>   * @loczrama: flag to dictate which TCM is at device address 0x0
>   * @released_from_reset: flag to signal when core is out of reset
> + * @unhalted: flag to signal when core is unhalted
>   */
>  struct k3_r5_core {
>   struct list_head elem;
> @@ -148,6 +149,7 @@ struct k3_r5_core {
>   u32 btcm_enable;
>   u32 loczrama;
>   bool released_from_reset;
> + bool unhalted;

Yet another flag?  @released_from_reset is not enough?  And why does it need to
be "unhalted" rather than something like "running"?  I will not move forward
with this patch until I get an R-B and a T-B from two other people at TI.

The above and the exchange with Jan Kiszka is furthering my belief that this
driver is up for a serious refactoring exercise.  From hereon I will only
consider bug fixes.

Thanks,
Mathieu

>  };
>  
>  /**
> @@ -448,13 +450,33 @@ static int k3_r5_rproc_prepare(struct rproc *rproc)
>  {
>   struct k3_r5_rproc *kproc = rproc->priv;
>   struct k3_r5_cluster *cluster = kproc->cluster;
> - struct k3_r5_core *core = kproc->core;
> + struct k3_r5_core *core0, *core1, *core = kproc->core;
>   struct device *dev = kproc->dev;
>   u32 ctrl = 0, cfg = 0, stat = 0;
>   u64 boot_vec = 0;
>   bool mem_init_dis;
>   int ret;
>  
> + /*
> +  * R5 cores require to be powered on sequentially, core0 should be in
> +  * higher power state than core1 in a cluster. So, wait for core0 to
> +  * power up before proceeding to core1 and put timeout of 2sec. This
> +  * waiting mechanism is necessary because rproc_auto_boot_callback() for
> +  * core1 can be called before core0 due to thread execution order.
> +  */
> + core0 = list_first_entry(&cluster->cores, struct k3_r5_core, elem);
> + core1 = list_last_entry(&cluster->cores, struct k3_r5_core, elem);
> + if (cluster->mode == CLUSTER_MODE_SPLIT && core == core1 &&
> + core0->released_from_reset == false) {
> + ret = wait_event_interruptible_timeout(cluster->core_transition,
> +
> core0->released_from_reset,
> +msecs_to_jiffies(2000));
> + if (ret <= 0) {
> + dev_err(dev, "can not power up core1 before core0");
> + return -EPERM;
> + }
> + }
> +
>   ret = ti_sci_proc_get_status(core->tsp, &boot_vec, &cfg, &ctrl, &stat);
>   if (ret < 0)
>   return ret;
> @@ -470,6 +492,12 @@ static int k3_r5_rproc_prepare(struct rproc *rproc)
>   return ret;
>   }
>  
> + /* Notify all threads in the wait queue when core state has changed so
> +  * that threads waiting for this condition can be executed.
> +  */
> + core->released_from_reset = true;
> + wake_up_interruptible(&cluster->core_transition);
> +
>   /*
>* Newer IP revisions like on J7200 SoCs support h/w auto-initialization
>* of TCMs, so there is no need to perform the s/w memzero. This bit is
> @@ -515,14 +543,46 @@ static int k3_r5_rproc_unprepare(struct rproc *rproc)
>  {
>   struct k3_r5_rproc *kproc = rproc->priv;
>   struct k3_r5_cluster *cluster = kproc->cluster;
> -

Re: [PATCH v5] remoteproc: xlnx: add sram support

[Mathieu Poirier]

On Wed, Sep 04, 2024 at 06:16:47PM +, Shah, Tanmay wrote:
> Hi Mathieu,
> 
> I agree with your assessment, and I agree with your proposal.
> I appreciate you fixing the patch before applying.
>

I have applied this patch.

> My email client (Thunderbird) has some issues, hence sending email form 
> different email
> client and so not formatted as expected. This will be fixed soon (before 
> sending anymore patches).
> 
> Thanks,
> Tanmay
> 
> On 9/4/24, 11:21 AM, "Mathieu Poirier"  <mailto:mathieu.poir...@linaro.org>> wrote:
> 
> 
> Good morning,
> 
> 
> On Fri, Aug 30, 2024 at 10:37:36AM -0700, Tanmay Shah wrote:
> > AMD-Xilinx zynqmp platform contains on-chip sram memory (OCM).
> > R5 cores can access OCM and access is faster than DDR memory but slower
> > than TCM memories available. Sram region can have optional multiple
> > power-domains. Platform management firmware is responsible
> > to operate these power-domains.
> > 
> > Signed-off-by: Tanmay Shah  > <mailto:tanmay.s...@amd.com>>
> > ---
> > 
> > Changes in v5:
> > - remoteproc: xlnx: remove genpool use for OCM sram
> > 
> > Changes in v4:
> > - Free previously allocalted genpool if adding carveouts fail for any
> > sram.
> > - add comment about sram size used in creating carveouts.
> > 
> > Changes in v3:
> > - make @sram an array rather than an array of pointers
> > - fix of_node_put usage to maintain proper refcount of node
> > - s/proprty/property
> > - Use gen pool framework for mapping sram address space.
> > 
> > Changes in v2:
> > - Expand commit message with power-domains related information.
> > 
> > 
> > drivers/remoteproc/xlnx_r5_remoteproc.c | 135 
> > 1 file changed, 135 insertions(+)
> > 
> > diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c 
> > b/drivers/remoteproc/xlnx_r5_remoteproc.c
> > index 2cea97c746fd..af4e0e53dc9d 100644
> > --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
> > +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
> > @@ -56,6 +56,17 @@ struct mem_bank_data {
> > char *bank_name;
> > };
> > 
> > +/**
> > + * struct zynqmp_sram_bank - sram bank description
> > + *
> > + * @sram_res: sram address region information
> > + * @da: device address of sram
> > + */
> > +struct zynqmp_sram_bank {
> > + struct resource sram_res;
> > + u32 da;
> > +};
> > +
> > /**
> > * struct mbox_info
> > *
> > @@ -120,6 +131,8 @@ static const struct mem_bank_data 
> > zynqmp_tcm_banks_lockstep[] = {
> > * struct zynqmp_r5_core
> > *
> > * @rsc_tbl_va: resource table virtual address
> > + * @sram: Array of sram memories assigned to this core
> > + * @num_sram: number of sram for this core
> > * @dev: device of RPU instance
> > * @np: device node of RPU instance
> > * @tcm_bank_count: number TCM banks accessible to this RPU
> > @@ -131,6 +144,8 @@ static const struct mem_bank_data 
> > zynqmp_tcm_banks_lockstep[] = {
> > */
> > struct zynqmp_r5_core {
> > void __iomem *rsc_tbl_va;
> > + struct zynqmp_sram_bank *sram;
> > + int num_sram;
> > struct device *dev;
> > struct device_node *np;
> > int tcm_bank_count;
> > @@ -494,6 +509,45 @@ static int add_mem_regions_carveout(struct rproc 
> > *rproc)
> > return 0;
> > }
> > 
> > +static int add_sram_carveouts(struct rproc *rproc)
> > +{
> > + struct zynqmp_r5_core *r5_core = rproc->priv;
> > + struct rproc_mem_entry *rproc_mem;
> > + struct zynqmp_sram_bank *sram;
> > + dma_addr_t dma_addr;
> > + size_t len;
> > + int da, i;
> > +
> > + for (i = 0; i < r5_core->num_sram; i++) {
> > + sram = &r5_core->sram[i];
> > +
> > + dma_addr = (dma_addr_t)sram->sram_res.start;
> > +
> > + len = resource_size(&sram->sram_res);
> > + da = sram->da;
> > +
> > + rproc_mem = rproc_mem_entry_init(&rproc->dev, NULL,
> > + (dma_addr_t)dma_addr,
> 
> 
> @dma_addr is already declared as a dma_addr_t, which is what
> rproc_mem_entry_init() is expecting. As such I do not see a reason for the
> extra casting - do you?
> 
> 
> If you agree with my assessment I am proposing to remove it before applying 
> the
> patch rather than having to send another revision.
> 
> 
> Let me know what you think.
> 
> 
> Thanks,
> Mathieu
> 
> 
> > + len, da,
> > + zynqmp_r5_mem_region_map,
> > + zynqmp_r5_mem_region_unmap,

Re: [PATCH] remoteproc:remove redundant dev_err message

[Mathieu Poirier]

On Thu, Sep 05, 2024 at 02:54:17AM +0800, Liu Jing wrote:
> devm_ioremap_resource already contains error message, so remove
> the redundant dev_err message
> 
> Signed-off-by: Liu Jing 
> 
> diff --git a/drivers/remoteproc/da8xx_remoteproc.c 
> b/drivers/remoteproc/da8xx_remoteproc.c
> index 9041a0e07fb2..289d5ce9f7af 100644
> --- a/drivers/remoteproc/da8xx_remoteproc.c
> +++ b/drivers/remoteproc/da8xx_remoteproc.c
> @@ -214,8 +214,6 @@ static int da8xx_rproc_get_internal_memories(struct 
> platform_device *pdev,
>  mem_names[i]);
>   drproc->mem[i].cpu_addr = devm_ioremap_resource(dev, res);
>   if (IS_ERR(drproc->mem[i].cpu_addr)) {
> - dev_err(dev, "failed to parse and map %s memory\n",
> - mem_names[i]);
>   return PTR_ERR(drproc->mem[i].cpu_addr);
>   }
>   drproc->mem[i].bus_addr = res->start;
> diff --git a/drivers/remoteproc/ingenic_rproc.c 
> b/drivers/remoteproc/ingenic_rproc.c
> index 9902cce28692..b3ee5c47001d 100644
> --- a/drivers/remoteproc/ingenic_rproc.c
> +++ b/drivers/remoteproc/ingenic_rproc.c
> @@ -186,7 +186,6 @@ static int ingenic_rproc_probe(struct platform_device 
> *pdev)
>   mem = platform_get_resource_byname(pdev, IORESOURCE_MEM, "aux");
>   vpu->aux_base = devm_ioremap_resource(dev, mem);
>   if (IS_ERR(vpu->aux_base)) {
> - dev_err(dev, "Failed to ioremap\n");
>   return PTR_ERR(vpu->aux_base);
>   }
>  
> @@ -197,7 +196,6 @@ static int ingenic_rproc_probe(struct platform_device 
> *pdev)
>   vpu->mem_info[i].base = devm_ioremap_resource(dev, mem);
>   if (IS_ERR(vpu->mem_info[i].base)) {
>   ret = PTR_ERR(vpu->mem_info[i].base);
> - dev_err(dev, "Failed to ioremap\n");
>   return ret;
>   }
>  
> diff --git a/drivers/remoteproc/keystone_remoteproc.c 
> b/drivers/remoteproc/keystone_remoteproc.c
> index 7e57b90bcaf8..a31f94a290c9 100644
> --- a/drivers/remoteproc/keystone_remoteproc.c
> +++ b/drivers/remoteproc/keystone_remoteproc.c
> @@ -312,8 +312,6 @@ static int keystone_rproc_of_get_memories(struct 
> platform_device *pdev,
>  mem_names[i]);
>   ksproc->mem[i].cpu_addr = devm_ioremap_resource(dev, res);
>   if (IS_ERR(ksproc->mem[i].cpu_addr)) {
> - dev_err(dev, "failed to parse and map %s memory\n",
> - mem_names[i]);
>   return PTR_ERR(ksproc->mem[i].cpu_addr);
>   }
>   ksproc->mem[i].bus_addr = res->start;
> diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
> index e744c07507ee..cb8ad16583c7 100644
> --- a/drivers/remoteproc/mtk_scp.c
> +++ b/drivers/remoteproc/mtk_scp.c
> @@ -1126,7 +1126,6 @@ static struct mtk_scp *scp_rproc_init(struct 
> platform_device *pdev,
>   res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "sram");
>   scp->sram_base = devm_ioremap_resource(dev, res);
>   if (IS_ERR(scp->sram_base)) {
> - dev_err(dev, "Failed to parse and map sram memory\n");
>   return ERR_CAST(scp->sram_base);
>   }

There is another instance in the Mediatek driver - please address.

Thanks,
Mathieu

>  
> diff --git a/drivers/remoteproc/omap_remoteproc.c 
> b/drivers/remoteproc/omap_remoteproc.c
> index 9ae2e831456d..07e707776cf9 100644
> --- a/drivers/remoteproc/omap_remoteproc.c
> +++ b/drivers/remoteproc/omap_remoteproc.c
> @@ -1201,8 +1201,6 @@ static int omap_rproc_of_get_internal_memories(struct 
> platform_device *pdev,
>   }
>   oproc->mem[i].cpu_addr = devm_ioremap_resource(dev, res);
>   if (IS_ERR(oproc->mem[i].cpu_addr)) {
> - dev_err(dev, "failed to parse and map %s memory\n",
> - data->mems[i].name);
>   return PTR_ERR(oproc->mem[i].cpu_addr);
>   }
>   oproc->mem[i].bus_addr = res->start;
> diff --git a/drivers/remoteproc/pru_rproc.c b/drivers/remoteproc/pru_rproc.c
> index 327f0c7ee3d6..85b95e025c17 100644
> --- a/drivers/remoteproc/pru_rproc.c
> +++ b/drivers/remoteproc/pru_rproc.c
> @@ -1047,8 +1047,6 @@ static int pru_rproc_probe(struct platform_device *pdev)
>  mem_names[i]);
>   pru->mem_regions[i].va = devm_ioremap_resource(dev, res);
>   if (IS_ERR(pru->mem_regions[i].va)) {
> - dev_err(dev, "failed to parse and map memory resource 
> %d %s\n",
> - i, mem_names[i]);
>   ret = PTR_ERR(pru->mem_regions[i].va);
>   return ret;
>   }
> diff --git a/drivers/remoteproc/qcom_q6v5_adsp.c 
> b/drivers/remoteproc/qcom_q6v5_adsp.c
> index 572

Re: [PATCH v5] remoteproc: xlnx: add sram support

[Mathieu Poirier]

Good morning,

On Fri, Aug 30, 2024 at 10:37:36AM -0700, Tanmay Shah wrote:
> AMD-Xilinx zynqmp platform contains on-chip sram memory (OCM).
> R5 cores can access OCM and access is faster than DDR memory but slower
> than TCM memories available. Sram region can have optional multiple
> power-domains. Platform management firmware is responsible
> to operate these power-domains.
> 
> Signed-off-by: Tanmay Shah 
> ---
> 
> Changes in v5:
>   - remoteproc: xlnx: remove genpool use for OCM sram
> 
> Changes in v4:
>   - Free previously allocalted genpool if adding carveouts fail for any
> sram.
>   - add comment about sram size used in creating carveouts.
> 
> Changes in v3:
>   - make @sram an array rather than an array of pointers
>   - fix of_node_put usage to maintain proper refcount of node
>   - s/proprty/property
>   - Use gen pool framework for mapping sram address space.
> 
> Changes in v2:
>   - Expand commit message with power-domains related information.
> 
> 
>  drivers/remoteproc/xlnx_r5_remoteproc.c | 135 
>  1 file changed, 135 insertions(+)
> 
> diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c 
> b/drivers/remoteproc/xlnx_r5_remoteproc.c
> index 2cea97c746fd..af4e0e53dc9d 100644
> --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
> +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
> @@ -56,6 +56,17 @@ struct mem_bank_data {
>   char *bank_name;
>  };
>  
> +/**
> + * struct zynqmp_sram_bank - sram bank description
> + *
> + * @sram_res: sram address region information
> + * @da: device address of sram
> + */
> +struct zynqmp_sram_bank {
> + struct resource sram_res;
> + u32 da;
> +};
> +
>  /**
>   * struct mbox_info
>   *
> @@ -120,6 +131,8 @@ static const struct mem_bank_data 
> zynqmp_tcm_banks_lockstep[] = {
>   * struct zynqmp_r5_core
>   *
>   * @rsc_tbl_va: resource table virtual address
> + * @sram: Array of sram memories assigned to this core
> + * @num_sram: number of sram for this core
>   * @dev: device of RPU instance
>   * @np: device node of RPU instance
>   * @tcm_bank_count: number TCM banks accessible to this RPU
> @@ -131,6 +144,8 @@ static const struct mem_bank_data 
> zynqmp_tcm_banks_lockstep[] = {
>   */
>  struct zynqmp_r5_core {
>   void __iomem *rsc_tbl_va;
> + struct zynqmp_sram_bank *sram;
> + int num_sram;
>   struct device *dev;
>   struct device_node *np;
>   int tcm_bank_count;
> @@ -494,6 +509,45 @@ static int add_mem_regions_carveout(struct rproc *rproc)
>   return 0;
>  }
>  
> +static int add_sram_carveouts(struct rproc *rproc)
> +{
> + struct zynqmp_r5_core *r5_core = rproc->priv;
> + struct rproc_mem_entry *rproc_mem;
> + struct zynqmp_sram_bank *sram;
> + dma_addr_t dma_addr;
> + size_t len;
> + int da, i;
> +
> + for (i = 0; i < r5_core->num_sram; i++) {
> + sram = &r5_core->sram[i];
> +
> + dma_addr = (dma_addr_t)sram->sram_res.start;
> +
> + len = resource_size(&sram->sram_res);
> + da = sram->da;
> +
> + rproc_mem = rproc_mem_entry_init(&rproc->dev, NULL,
> +  (dma_addr_t)dma_addr,

@dma_addr is already declared as a dma_addr_t, which is what
rproc_mem_entry_init() is expecting.  As such I do not see a reason for the
extra casting - do you?

If you agree with my assessment I am proposing to remove it before applying the
patch rather than having to send another revision.

Let me know what you think.

Thanks,
Mathieu

> +  len, da,
> +  zynqmp_r5_mem_region_map,
> +  zynqmp_r5_mem_region_unmap,
> +  sram->sram_res.name);
> + if (!rproc_mem) {
> + dev_err(&rproc->dev, "failed to add sram %s da=0x%x, 
> size=0x%lx",
> + sram->sram_res.name, da, len);
> + return -ENOMEM;
> + }
> +
> + rproc_add_carveout(rproc, rproc_mem);
> + rproc_coredump_add_segment(rproc, da, len);
> +
> + dev_dbg(&rproc->dev, "sram carveout %s addr=%llx, da=0x%x, 
> size=0x%lx",
> + sram->sram_res.name, dma_addr, da, len);
> + }
> +
> + return 0;
> +}
> +
>  /*
>   * tcm_mem_unmap()
>   * @rproc: single R5 core's corresponding rproc instance
> @@ -669,6 +723,12 @@ static int zynqmp_r5_rproc_prepare(struct rproc *rproc)
>   return ret;
>   }
>  
> + ret = add_sram_carveouts(rproc);
> + if (ret) {
> + dev_err(&rproc->dev, "failed to get sram carveout %d\n", ret);
> + return ret;
> + }
> +
>   return 0;
>  }
>  
> @@ -881,6 +941,77 @@ static struct zynqmp_r5_core 
> *zynqmp_r5_add_rproc_core(struct device *cdev)
>   return ERR_PTR(ret);
>  }
>  
> +static int zynqmp_r5_get_sram_banks(struct zynqmp_r5_core *r5_co

Re: [PATCH] remoteproc:remove redundant dev_err message

[Mathieu Poirier]

Hi,

There are several other instances such as these in the remoteproc subsystem.
Please send another revision that is addressing them all.

Thanks,
Mathieu

On Wed, Sep 04, 2024 at 10:09:49AM +0800, Liu Jing wrote:
> devm_ioremap_resource already contains error message, so remove
> the redundant dev_err message
> 
> Signed-off-by: Liu Jing 
> diff --git a/drivers/remoteproc/st_slim_rproc.c 
> b/drivers/remoteproc/st_slim_rproc.c
> index d17719384c16..a6e50f51c794 100644
> --- a/drivers/remoteproc/st_slim_rproc.c
> +++ b/drivers/remoteproc/st_slim_rproc.c
> @@ -251,7 +251,6 @@ struct st_slim_rproc *st_slim_rproc_alloc(struct 
> platform_device *pdev,
>  
>   slim_rproc->mem[i].cpu_addr = devm_ioremap_resource(dev, res);
>   if (IS_ERR(slim_rproc->mem[i].cpu_addr)) {
> - dev_err(&pdev->dev, "devm_ioremap_resource failed\n");
>   err = PTR_ERR(slim_rproc->mem[i].cpu_addr);
>   goto err;
>   }
> @@ -262,7 +261,6 @@ struct st_slim_rproc *st_slim_rproc_alloc(struct 
> platform_device *pdev,
>   res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "slimcore");
>   slim_rproc->slimcore = devm_ioremap_resource(dev, res);
>   if (IS_ERR(slim_rproc->slimcore)) {
> - dev_err(&pdev->dev, "failed to ioremap slimcore IO\n");
>   err = PTR_ERR(slim_rproc->slimcore);
>   goto err;
>   }
> @@ -270,7 +268,6 @@ struct st_slim_rproc *st_slim_rproc_alloc(struct 
> platform_device *pdev,
>   res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "peripherals");
>   slim_rproc->peri = devm_ioremap_resource(dev, res);
>   if (IS_ERR(slim_rproc->peri)) {
> - dev_err(&pdev->dev, "failed to ioremap peripherals IO\n");
>   err = PTR_ERR(slim_rproc->peri);
>   goto err;
>   }
> -- 
> 2.33.0
> 
> 
> 

Re: [PATCH v2] remoteproc: k3-r5: Delay notification of wakeup event

[Mathieu Poirier]

On Tue, 3 Sept 2024 at 04:15, Beleswar Prasad Padhi  wrote:
>
> Hi Mathieu,
>
> On 20-08-2024 16:20, Beleswar Padhi wrote:
> > From: Udit Kumar 
> >
> > Few times, core1 was scheduled to boot first before core0, which leads
> > to error:
> >
> > 'k3_r5_rproc_start: can not start core 1 before core 0'.
> >
> > This was happening due to some scheduling between prepare and start
> > callback. The probe function waits for event, which is getting
> > triggered by prepare callback. To avoid above condition move event
> > trigger to start instead of prepare callback.
> >
> > Fixes: 61f6f68447ab ("remoteproc: k3-r5: Wait for core0 power-up before 
> > powering up core1")
>
>
> Please put this patch on hold. I have some additional changelog that
> should go in v3.
>

I applied this patch a couple of weeks ago - are those changes to the
code?  If so please send another patch on top of rproc-next.

> Thanks,
> Beleswar
>
> > Signed-off-by: Udit Kumar 
> > [ Applied wakeup event trigger only for Split-Mode booted rprocs ]
> > Signed-off-by: Beleswar Padhi 
> > ---
> > v2: Changelog:
> > * Mathieu
> > 1) Rebased changes on top of -next-20240820 tag.
> >
> > Link to v1:
> > https://lore.kernel.org/all/20240809060132.308642-1-b-pa...@ti.com/
> >
> >   drivers/remoteproc/ti_k3_r5_remoteproc.c | 5 +++--
> >   1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c 
> > b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> > index 8a63a9360c0f..e61e53381abc 100644
> > --- a/drivers/remoteproc/ti_k3_r5_remoteproc.c
> > +++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> > @@ -469,8 +469,6 @@ static int k3_r5_rproc_prepare(struct rproc *rproc)
> >   ret);
> >   return ret;
> >   }
> > - core->released_from_reset = true;
> > - wake_up_interruptible(&cluster->core_transition);
> >
> >   /*
> >* Newer IP revisions like on J7200 SoCs support h/w 
> > auto-initialization
> > @@ -587,6 +585,9 @@ static int k3_r5_rproc_start(struct rproc *rproc)
> >   ret = k3_r5_core_run(core);
> >   if (ret)
> >   return ret;
> > +
> > + core->released_from_reset = true;
> > + wake_up_interruptible(&cluster->core_transition);
> >   }
> >
> >   return 0;

Re: [PATCH] remoteproc: k3-r5: Fix error handling when power-up failed

[Mathieu Poirier]

On Thu, Aug 22, 2024 at 10:52:40AM +0530, Beleswar Prasad Padhi wrote:
> 
> On 21-08-2024 23:40, Jan Kiszka wrote:
> > On 21.08.24 07:30, Beleswar Prasad Padhi wrote:
> > > On 19-08-2024 20:54, Jan Kiszka wrote:
> > > > From: Jan Kiszka 
> > > > 
> > > > By simply bailing out, the driver was violating its rule and internal
> > > 
> > > Using device lifecycle managed functions to register the rproc
> > > (devm_rproc_add()), bailing out with an error code will work.
> > > 
> > > > assumptions that either both or no rproc should be initialized. E.g.,
> > > > this could cause the first core to be available but not the second one,
> > > > leading to crashes on its shutdown later on while trying to dereference
> > > > that second instance.
> > > > 
> > > > Fixes: 61f6f68447ab ("remoteproc: k3-r5: Wait for core0 power-up
> > > > before powering up core1")
> > > > Signed-off-by: Jan Kiszka 
> > > > ---
> > > >    drivers/remoteproc/ti_k3_r5_remoteproc.c | 3 ++-
> > > >    1 file changed, 2 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c
> > > > b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> > > > index 39a47540c590..eb09d2e9b32a 100644
> > > > --- a/drivers/remoteproc/ti_k3_r5_remoteproc.c
> > > > +++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> > > > @@ -1332,7 +1332,7 @@ static int k3_r5_cluster_rproc_init(struct
> > > > platform_device *pdev)
> > > >    dev_err(dev,
> > > >    "Timed out waiting for %s core to power up!\n",
> > > >    rproc->name);
> > > > -    return ret;
> > > > +    goto err_powerup;
> > > >    }
> > > >    }
> > > >    @@ -1348,6 +1348,7 @@ static int k3_r5_cluster_rproc_init(struct
> > > > platform_device *pdev)
> > > >    }
> > > >    }
> > > >    +err_powerup:
> > > >    rproc_del(rproc);
> > > 
> > > Please use devm_rproc_add() to avoid having to do rproc_del() manually
> > > here.
> > This is just be the tip of the iceberg. The whole code needs to be
> > reworked accordingly so that we can drop these goto, not just this one.
> 
> 
> You are correct. Unfortunately, the organic growth of this driver has
> resulted in a need to refactor. I plan on doing this and post the
> refactoring soon. This should be part of the overall refactoring as
> suggested by Mathieu[2]. But for the immediate problem, your fix does patch
> things up.. hence:
> 
> Acked-by: Beleswar Padhi 
>

I have applied this patch.

Thanks,
Mathieu

> [2]: https://lore.kernel.org/all/Zr4w8Vj0mVo5sBsJ@p14s/
> 
> > Just look at k3_r5_reserved_mem_init. Your change in [1] was also too
> > early in this regard, breaking current error handling additionally.
> 
> 
> 
> Curious, Could you point out how does the change in [1] breaks current error
> handling?
> 
> > 
> > I'll stop my whac-a-mole. Someone needs to sit down and do that for the
> > complete code consistently. And test the error cases.
> > 
> > Jan
> > 
> > [1]
> > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=f3f11cfe890733373ddbb1ce8991ccd4ee5e79e1
> > 
> > > >    err_add:
> > > >    k3_r5_reserved_mem_exit(kproc);

Re: [PATCH v4] remoteproc: xlnx: add sram support

[Mathieu Poirier]

Good morning,

First and foremost the overall structure of your code has improved immensely and
I commend you for that.

On Mon, Aug 19, 2024 at 10:09:38AM -0700, Tanmay Shah wrote:
> AMD-Xilinx zynqmp platform contains on-chip sram memory (OCM).
> R5 cores can access OCM and access is faster than DDR memory but slower
> than TCM memories available. Sram region can have optional multiple
> power-domains. Platform management firmware is responsible
> to operate these power-domains.
> 
> Signed-off-by: Tanmay Shah 
> ---
> 
> Changes in v4:
>   - Free previously allocalted genpool if adding carveouts fail for any
> sram.
>   - add comment about sram size used in creating carveouts.
> 
> Changes in v3:
>   - make @sram an array rather than an array of pointers
>   - fix of_node_put usage to maintain proper refcount of node
>   - s/proprty/property
>   - Use gen pool framework for mapping sram address space.
> 
> Changes in v2:
>   - Expand commit message with power-domains related information.
> 
>  drivers/remoteproc/xlnx_r5_remoteproc.c | 165 
>  1 file changed, 165 insertions(+)
> 
> diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c 
> b/drivers/remoteproc/xlnx_r5_remoteproc.c
> index 2cea97c746fd..6d2ac7b85c8a 100644
> --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
> +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
> @@ -7,6 +7,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -56,6 +57,21 @@ struct mem_bank_data {
>   char *bank_name;
>  };
>  
> +/**
> + * struct zynqmp_sram_bank - sram bank description
> + *
> + * @sram_pool: gen pool for his sram
> + * @sram_res: sram address region information
> + * @va: virtual address of allocated genpool
> + * @da: device address of sram
> + */
> +struct zynqmp_sram_bank {
> + struct gen_pool *sram_pool;
> + struct resource sram_res;
> + void __iomem *va;
> + u32 da;
> +};
> +
>  /**
>   * struct mbox_info
>   *
> @@ -120,6 +136,8 @@ static const struct mem_bank_data 
> zynqmp_tcm_banks_lockstep[] = {
>   * struct zynqmp_r5_core
>   *
>   * @rsc_tbl_va: resource table virtual address
> + * @sram: Array of sram memories assigned to this core
> + * @num_sram: number of sram for this core
>   * @dev: device of RPU instance
>   * @np: device node of RPU instance
>   * @tcm_bank_count: number TCM banks accessible to this RPU
> @@ -131,6 +149,8 @@ static const struct mem_bank_data 
> zynqmp_tcm_banks_lockstep[] = {
>   */
>  struct zynqmp_r5_core {
>   void __iomem *rsc_tbl_va;
> + struct zynqmp_sram_bank *sram;
> + int num_sram;
>   struct device *dev;
>   struct device_node *np;
>   int tcm_bank_count;
> @@ -494,6 +514,56 @@ static int add_mem_regions_carveout(struct rproc *rproc)
>   return 0;
>  }
>  
> +static int add_sram_carveouts(struct rproc *rproc)
> +{
> + struct zynqmp_r5_core *r5_core = rproc->priv;
> + struct rproc_mem_entry *rproc_mem;
> + struct zynqmp_sram_bank *sram;
> + size_t len, pool_size;
> + dma_addr_t dma_addr;
> + int da, i;
> +
> + for (i = 0; i < r5_core->num_sram; i++) {
> + sram = &r5_core->sram[i];
> +
> + dma_addr = (dma_addr_t)sram->sram_res.start;
> +
> + /* Use actual resource size, as genpool size can be rounded up 
> */
> + len = resource_size(&sram->sram_res);
> + da = sram->da;
> +
> + pool_size = gen_pool_size(sram[i].sram_pool);
> + sram->va = (void __iomem *)gen_pool_alloc(sram->sram_pool, 
> pool_size);

The genpool subsystem API is used to allocate the genpool but other than
being free'd int zynqmp_r5_rproc_unprepare(), nothing is done with the genpool.
Do you have plans to change that in an upcoming patchset?  If not please remove.

Thanks,
Mathieu

> + if (!sram->va) {
> + dev_err(r5_core->dev, "failed to alloc sram idx %d 
> pool\n", i);
> + goto fail_add_sram_carveouts;
> + }
> +
> + rproc_mem = rproc_mem_entry_init(&rproc->dev, sram->va,
> +  (dma_addr_t)dma_addr,
> +  len, da,
> +  NULL, NULL,
> +  sram->sram_res.name);
> +
> + rproc_add_carveout(rproc, rproc_mem);
> + rproc_coredump_add_segment(rproc, da, len);
> +
> + dev_dbg(&rproc->dev, "sram carveout %s addr=%llx, da=0x%x, 
> size=0x%lx",
> + sram->sram_res.name, dma_addr, da, len);
> + }
> +
> + return 0;
> +
> +fail_add_sram_carveouts:
> + while (--i > 0) {
> + pool_size = gen_pool_size(sram[i].sram_pool);
> + gen_pool_free(sram[i].sram_pool,
> +   (unsigned long)r5_core->sram[i].va, pool_size);
> + }
> +
> + return -ENOMEM;
> +}
> +
>  /*
>   * tcm_mem_unmap()

Re: [PATCH v3 0/2] remoteproc: imx_rproc: support non-blocking tx for i.MX7ULP

[Mathieu Poirier]

On Thu, Aug 22, 2024 at 09:48:48PM +0800, Peng Fan (OSS) wrote:
> The i.MX7ULP Cortex-A7 is under control of Cortex-M4. The i.MX7ULP Linux
> poweroff and restart rely on rpmsg driver to send a message to Cortex-M4
> firmware. Then Cortex-A7 could poweroff or restart by Cortex-M4 to
> configure the i.MX7ULP power controller properly.
> 
> However the reboot and restart kernel common code use atomic notifier,
> see kernel/reboot.c: do_kernel_power_off, do_kernel_restart.
> Linux 'poweroff' cmd will trigger kernel 'do_kernel_power_off'
> Linux 'reboot' cmd will trigger kernel 'do_kernel_restart'.
> 
> Power off and restart are totally different operations and are not
> complementary. So need to make sure the mailbox be changed to non-blocking
> mode in SYS_OFF_MODE_POWER_OFF_PREPARE and SYS_OFF_MODE_RESTART_PREPARE
> stage. Otherwise with blocking tx mailbox, there will be kernel dump,
> because of blocking mailbox will use wait_for_completion_timeout. In the
> poweroff or restart case, there is no need to wait, because after M4 got
> the message, M4 will put A7 to reboot or poweroff.
> 
> patch 1 is to support non-blocking tx mailbox channel
> patch 2 is to switch to non-blocking tx for system poweroff or restart.
> 
> Signed-off-by: Peng Fan 
> ---
> Changes in v3:
> - patch 2: Introduce an flags entry for dcfg and set IMX_RPROC_NEED_SYSTEM_OFF
>   for i.MX7ULP, drop used "struct sys_off_data data" and add comment(per 
> Frank).
>   Drop R-b of patch 2 because of this change.
> - Patch 1: commit log rewritten and R-b dropped.
>   (Thanks to Daniel).
> - Update patch 2 commit log and cover-letter to clarify reboot and
>   poweroff are different operations and not complementary 
>   (Thanks to Daniel).
> - Link to v2: 
> https://lore.kernel.org/r/20240719-imx_rproc-v2-0-cd8549aa3...@nxp.com
> 
> Changes in v2:
> - Separated patch 5,6 from v1
> - Update commit patch 1 with adding "No functional changes"
> - Link to v1: 
> https://lore.kernel.org/r/20240712-imx_rproc-v1-0-7bcf6732d...@nxp.com
> 
> ---
> Peng Fan (2):
>   remoteproc: imx_rproc: Allow setting of the mailbox transmit mode
>   remoteproc: imx_rproc: Add support for poweroff and reboot
> 
>  drivers/remoteproc/imx_rproc.c | 54 
> +-
>  drivers/remoteproc/imx_rproc.h |  4 
>  2 files changed, 52 insertions(+), 6 deletions(-)

I have applied this set.

Thanks,
Mathieu

> ---
> base-commit: 33a32de2d79c051f27ed57c4ac90cdb406f91928
> change-id: 20240712-imx_rproc-25f3ab753c58
> 
> Best regards,
> -- 
> Peng Fan 
> 

Re: [PATCH 1/1] remoteproc: Use iommu_paging_domain_alloc()

[Mathieu Poirier]

Hi Baolu,

Sorry for the late reply, this slipped through the cracks.

On Mon, Aug 12, 2024 at 03:28:11PM +0800, Lu Baolu wrote:
> An iommu domain is allocated in rproc_enable_iommu() and is attached to
> rproc->dev.parent in the same function.
> 
> Use iommu_paging_domain_alloc() to make it explicit.
> 
> Signed-off-by: Lu Baolu 
> Reviewed-by: Jason Gunthorpe 
> Link: 
> https://lore.kernel.org/r/2024061008.88197-13-baolu...@linux.intel.com
> ---
>  drivers/remoteproc/remoteproc_core.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/remoteproc/remoteproc_core.c 
> b/drivers/remoteproc/remoteproc_core.c
> index f276956f2c5c..eb66f78ec8b7 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -109,10 +109,10 @@ static int rproc_enable_iommu(struct rproc *rproc)
>   return 0;
>   }
>  
> - domain = iommu_domain_alloc(dev->bus);
> - if (!domain) {
> + domain = iommu_paging_domain_alloc(dev);

I'm a little hesitant here.  Function iommu_domain_alloc() passes NULL two the
second argument of __iommu_domain_alloc() while iommu_paging_domain_alloc()
provides a 'dev'.  I don't have any HW to test on and I am not familiar enough
with the IOMMU subsystem to confidently more forward.

I am asking the Qualcomm (Bjorn and friends) and TI crew (Beleswar, Andrew,
Nishanth and Hari) to test this patch on their IOMMU devices and get back to me
with a "Tested-by".

Thanks,
Mathieu

> + if (IS_ERR(domain)) {
>   dev_err(dev, "can't alloc iommu domain\n");
> - return -ENOMEM;
> + return PTR_ERR(domain);
>   }
>  
>   iommu_set_fault_handler(domain, rproc_iommu_fault, rproc);
> -- 
> 2.34.1
> 

Re: [PATCH v11 3/9] remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem

[Mathieu Poirier]

On Mon, Aug 19, 2024 at 10:54:11AM -0500, Andrew Davis wrote:
> On 8/19/24 10:39 AM, Krzysztof Kozlowski wrote:
> > On 19/08/2024 17:32, Mathieu Poirier wrote:
> > 
> > > > > > Please remove.
> > > > > Forget this comment since it would cause an error in __rproc_detach().
> > > > > 
> > > > > > Other than the above I'm good with this driver.  That said I can't 
> > > > > > move forward
> > > > > > without a nod from the DT crew.  I also noticed a fair amount of 
> > > > > > code
> > > > > > duplication with the k3_r5 and k3_dsp drivers.  Dealing with that 
> > > > > > should not be
> > > > > > part of the current work but will need to be done before another k3 
> > > > > > driver can
> > > > > > be merged.
> > > > > > 
> > > > 
> > > > > The above still apply though.
> > > > 
> > > > Me or Nishanth will pick up the SoC DT patches via TI SoC tree, once the
> > > > driver patches are merged. Feel free to ignore those but queue
> > > > dt-bindings (already has DT maintainers ack) and driver patches via
> > > > rproc tree.
> > > > 
> > > 
> > > Can you provide a link where the DT maintainers have acknowledged the 
> > > bindings?
> > 
> > The reviewed-by tag serves as acknowledgment as well and the binding
> > patch has it. Conor gave it on some earlier version of the patchset. I
> > did not check if there were any significant changes in the meantime, though.
> > 
> 
> Was reviewed in v8:
> https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240424190612.17349-2-...@ti.com/#3302840
>

I didn't notice Conor had joined the DT crew and as such was expecting something
from either Rob or Krzysztof.  I am applying this set.

Thanks,
Mathieu

> If there was any significant changes since I would have dropped the tag.
> 
> Andrew
> 
> > 
> > Best regards,
> > Krzysztof
> > 

Re: [PATCH v2 2/2] remoteproc: imx_rproc: handle system off for i.MX7ULP

[Mathieu Poirier]

On Wed, 21 Aug 2024 at 02:32, Daniel Baluta  wrote:
>
> Hello Mathieu,
>
> I've talked to Peng and if my understanding is correct I think the patch is 
> OK.
> Maybe we can split the patch in two:
> * first, adding the power off callback with explanations.
> * second, adding the restart callback with explanations.
>
> And also add a more detailed explanation.
>
> Power off and restart are totally different operations and are not 
> complementary
> as I thought in the beginning. There are not like suspend/resume for example.
>
> > >  static int imx_rproc_probe(struct platform_device *pdev)
> > >  {
> > >   struct device *dev = &pdev->dev;
> > > @@ -1104,6 +1122,24 @@ static int imx_rproc_probe(struct platform_device 
> > > *pdev)
> > >   if (rproc->state != RPROC_DETACHED)
> > >   rproc->auto_boot = of_property_read_bool(np, 
> > > "fsl,auto-boot");
> > >
> > > + if (of_device_is_compatible(dev->of_node, "fsl,imx7ulp-cm4")) {
> > > + ret = devm_register_sys_off_handler(dev, 
> > > SYS_OFF_MODE_POWER_OFF_PREPARE,
> > > + SYS_OFF_PRIO_DEFAULT,
> > > + 
> > > imx_rproc_sys_off_handler, rproc);
> >
> > Why does the mailbox needs to be set up again when the system is going 
> > down...
>
> Scenario: We call Linux *shutdown -P * command to power off the machine.
>
> At this point mailbox TX operation is configured as *blocking*. Power
> off is done via
> an atomic notifier call which doesn't allow blocking. If we do so we
> will endup in a kernel crash.
>
> So, at this moment we setup again the mailboxes configuring them with
> *non-blocking* option.
>
> >
> > > + if (ret) {
> > > + dev_err(dev, "register power off handler 
> > > failure\n");
> > > + goto err_put_clk;
> > > + }
> > > +
> > > + ret = devm_register_sys_off_handler(dev, 
> > > SYS_OFF_MODE_RESTART_PREPARE,
> > > + SYS_OFF_PRIO_DEFAULT,
> > > + 
> > > imx_rproc_sys_off_handler, rproc);
> >
> > ... and why does it need to be free'd when the system is going up?
>
> System is not going up here. System is running and we do a reboot.
>

Ah!  This is still on the downward path - I thought
"SYS_OFF_MODE_RESTART_PREPARE" was associated with the upward path,
when the system is restarted after a shutdown or a reboot.  That is
where the confusion came from.

> Scenario: We call Linux *shutdown -r* command to reboot the machine.
>
> Similarly, mailboxes are already set and configured as *blocking*. We
> cannot use the mailboxes
> as they are because reboot is done via an atomic notifier which if we
> call a blocking function it will endup in crash.
>
> So, we need to free the existing mailbox and create new ones with the
> *non-blocking* options.
>
> I think this is really fair to me. The one thing, I admit we must work
> on, create a better commit message.
>
> What do you say? Does this work for you?
>

Things are clear now and I agree with the implementation.  No need for
two separate patches, just a re-worked changelog.

Thanks,
Mathieu

> Thanks a lot for your help!

Re: [PATCH] remoteproc: k3-r5: Delay notification of wakeup event

[Mathieu Poirier]

On Fri, Aug 09, 2024 at 11:31:32AM +0530, Beleswar Padhi wrote:
> From: Udit Kumar 
> 
> Few times, core1 was scheduled to boot first before core0, which leads
> to error:
> 
> 'k3_r5_rproc_start: can not start core 1 before core 0'.
> 
> This was happening due to some scheduling between prepare and start
> callback. The probe function waits for event, which is getting
> triggered by prepare callback. To avoid above condition move event
> trigger to start instead of prepare callback.

I can see the race condition.

> 
> Fixes: 61f6f68447ab ("remoteproc: k3-r5: Wait for core0 power-up before 
> powering up core1")
> Signed-off-by: Udit Kumar 
> [ Applied wakeup event trigger only for Split-Mode booted rprocs ]
> Signed-off-by: Beleswar Padhi 
> ---
>  drivers/remoteproc/ti_k3_r5_remoteproc.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c 
> b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> index 39a47540c590..f1710a61247f 100644
> --- a/drivers/remoteproc/ti_k3_r5_remoteproc.c
> +++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> @@ -464,8 +464,6 @@ static int k3_r5_rproc_prepare(struct rproc *rproc)
>   ret);
>   return ret;
>   }
> - core->released_from_reset = true;
> - wake_up_interruptible(&cluster->core_transition);
>  
>   /*
>* Newer IP revisions like on J7200 SoCs support h/w auto-initialization
> @@ -587,6 +585,9 @@ static int k3_r5_rproc_start(struct rproc *rproc)
>   ret = k3_r5_core_run(core);
>   if (ret)
>   goto put_mbox;
> +
> + core->released_from_reset = true;
> + wake_up_interruptible(&cluster->core_transition);

This patch doesn't apply due to recent changes made to the k3-r5 driver.  Please
rebase and resubmit.

Thanks,
Mathieu

>   }
>  
>   return 0;
> -- 
> 2.34.1
> 

Re: [PATCH v11 3/9] remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem

[Mathieu Poirier]

Hey Vignesh.

On Mon, Aug 19, 2024 at 02:02:31PM +0530, Vignesh Raghavendra wrote:
> [...]
> 
> Hi Mathieu
> 
> On 16/08/24 20:06, Mathieu Poirier wrote:
> >>> +/*
> >>> + * Attach to a running M4 remote processor (IPC-only mode)
> >>> + *
> >>> + * The remote processor is already booted, so there is no need to issue 
> >>> any
> >>> + * TI-SCI commands to boot the M4 core. This callback is used only in 
> >>> IPC-only
> >>> + * mode.
> >>> + */
> >>> +static int k3_m4_rproc_attach(struct rproc *rproc)
> >>> +{
> >>> + struct k3_m4_rproc *kproc = rproc->priv;
> >>> + int ret;
> >>> +
> >>> + ret = k3_m4_rproc_ping_mbox(kproc);
> >>> + if (ret)
> >>> + return ret;
> >>> +
> >>> + return 0;
> >>> +}
> >>> +
> >>> +/*
> >>> + * Detach from a running M4 remote processor (IPC-only mode)
> >>> + *
> >>> + * This rproc detach callback performs the opposite operation to attach
> >>> + * callback, the M4 core is not stopped and will be left to continue to
> >>> + * run its booted firmware. This callback is invoked only in IPC-only 
> >>> mode.
> >>> + */
> >>> +static int k3_m4_rproc_detach(struct rproc *rproc)
> >>> +{
> >>> + return 0;
> >>> +}
> >> Please remove.
> > Forget this comment since it would cause an error in __rproc_detach().  
> > 
> >> Other than the above I'm good with this driver.  That said I can't move 
> >> forward
> >> without a nod from the DT crew.  I also noticed a fair amount of code
> >> duplication with the k3_r5 and k3_dsp drivers.  Dealing with that should 
> >> not be
> >> part of the current work but will need to be done before another k3 driver 
> >> can
> >> be merged.
> >>
> 
> > The above still apply though.
> 
> Me or Nishanth will pick up the SoC DT patches via TI SoC tree, once the
> driver patches are merged. Feel free to ignore those but queue
> dt-bindings (already has DT maintainers ack) and driver patches via
> rproc tree.
> 

Can you provide a link where the DT maintainers have acknowledged the bindings?

> 
> -- 
> Regards
> Vignesh

Re: [PATCH v4 2/3] remoteproc: k3-r5: Acquire mailbox handle during probe routine

[Mathieu Poirier]

On Fri, Aug 16, 2024 at 01:23:59PM +0530, Beleswar Prasad Padhi wrote:
> Hi Mathieu,
> 
> On 14-08-2024 21:22, Mathieu Poirier wrote:
> > Hi Beleswar, On Thu, Aug 08, 2024 at 01: 11: 26PM +0530, Beleswar Padhi
> > wrote: > Acquire the mailbox handle during device probe and do not
> > release handle > in stop/detach routine or error paths. This removes the
> > redundant > requests for
> > ZjQcmQRYFpfptBannerStart
> > Report Suspicious
> > <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/G3vK!vldnVV7DH2eSIoaksHjpMPogloWUPfAcp2-dEVbMoE1YA3kGFXdJXGAJUKJm$>
> > 
> > ZjQcmQRYFpfptBannerEnd
> > Hi Beleswar,
> > 
> > On Thu, Aug 08, 2024 at 01:11:26PM +0530, Beleswar Padhi wrote:
> > > Acquire the mailbox handle during device probe and do not release handle
> > > in stop/detach routine or error paths. This removes the redundant
> > > requests for mbox handle later during rproc start/attach. This also
> > > allows to defer remoteproc driver's probe if mailbox is not probed yet.
> > > > Signed-off-by: Beleswar Padhi 
> > > ---
> > >  drivers/remoteproc/ti_k3_r5_remoteproc.c | 78 +---
> > >  1 file changed, 30 insertions(+), 48 deletions(-)
> > > > diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c
> > b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> > > index 57067308b3c0..8a63a9360c0f 100644
> > > --- a/drivers/remoteproc/ti_k3_r5_remoteproc.c
> > > +++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> > > @@ -194,6 +194,10 @@ static void k3_r5_rproc_mbox_callback(struct 
> > > mbox_client *client, void *data)
> > >   const char *name = kproc->rproc->name;
> > >   u32 msg = omap_mbox_message(data);
> > >  > +  /* Do not forward message from a detached core */
> > > + if (kproc->rproc->state == RPROC_DETACHED)
> > > + return;
> > > +
> > >   dev_dbg(dev, "mbox msg: 0x%x\n", msg);
> > >  >switch (msg) {
> > > @@ -229,6 +233,10 @@ static void k3_r5_rproc_kick(struct rproc *rproc, 
> > > int vqid)
> > >   mbox_msg_t msg = (mbox_msg_t)vqid;
> > >   int ret;
> > >  > +  /* Do not forward message to a detached core */
> > > + if (kproc->rproc->state == RPROC_DETACHED)
> > > + return;
> > > +
> > >   /* send the index of the triggered virtqueue in the mailbox payload */
> > >   ret = mbox_send_message(kproc->mbox, (void *)msg);
> > >   if (ret < 0)
> > > @@ -399,12 +407,9 @@ static int k3_r5_rproc_request_mbox(struct rproc 
> > > *rproc)
> > >   client->knows_txdone = false;
> > >  >kproc->mbox = mbox_request_channel(client, 0);
> > > - if (IS_ERR(kproc->mbox)) {
> > > - ret = -EBUSY;
> > > - dev_err(dev, "mbox_request_channel failed: %ld\n",
> > > - PTR_ERR(kproc->mbox));
> > > - return ret;
> > > - }
> > > + if (IS_ERR(kproc->mbox))
> > > + return dev_err_probe(dev, PTR_ERR(kproc->mbox),
> > > +  "mbox_request_channel failed\n");
> > >  >/*
> > >* Ping the remote processor, this is only for sanity-sake for now;
> > > @@ -552,10 +557,6 @@ static int k3_r5_rproc_start(struct rproc *rproc)
> > >   u32 boot_addr;
> > >   int ret;
> > >  > -  ret = k3_r5_rproc_request_mbox(rproc);
> > > - if (ret)
> > > - return ret;
> > > -
> > >   boot_addr = rproc->bootaddr;
> > >   /* TODO: add boot_addr sanity checking */
> > >   dev_dbg(dev, "booting R5F core using boot addr = 0x%x\n", boot_addr);
> > > @@ -564,7 +565,7 @@ static int k3_r5_rproc_start(struct rproc *rproc)
> > >   core = kproc->core;
> > >   ret = ti_sci_proc_set_config(core->tsp, boot_addr, 0, 0);
> > >   if (ret)
> > > - goto put_mbox;
> > > + return ret;
> > >  >/* unhalt/run all applicable cores */
> > >   if (cluster->mode == CLUSTER_MODE_LOCKSTEP) {
> > > @@ -580,13 +581,12 @@ static int k3_r5_rproc_start(struct rproc *rproc)
> > >   if (core != core0 && core0->rproc->state == RPROC_OFFLINE) {
> > >   dev_err(dev, "%s: can not start core 1 before core 0\n",
> > >   __func__);
> > > - ret = -EPERM;
> > > - goto put_mbox;
> &g

Re: [PATCH v11 3/9] remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem

[Mathieu Poirier]

On Thu, Aug 15, 2024 at 10:46:41AM -0600, Mathieu Poirier wrote:
> Hi,
> 
> On Fri, Aug 02, 2024 at 10:21:03AM -0500, Andrew Davis wrote:
> > From: Martyn Welch 
> > 
> > The AM62x and AM64x SoCs of the TI K3 family has a Cortex M4F core in
> > the MCU domain. This core is typically used for safety applications in a
> > stand alone mode. However, some application (non safety related) may
> > want to use the M4F core as a generic remote processor with IPC to the
> > host processor. The M4F core has internal IRAM and DRAM memories and are
> > exposed to the system bus for code and data loading.
> > 
> > A remote processor driver is added to support this subsystem, including
> > being able to load and boot the M4F core. Loading includes to M4F
> > internal memories and predefined external code/data memories. The
> > carve outs for external contiguous memory is defined in the M4F device
> > node and should match with the external memory declarations in the M4F
> > image binary. The M4F subsystem has two resets. One reset is for the
> > entire subsystem i.e including the internal memories and the other, a
> > local reset is only for the M4F processing core. When loading the image,
> > the driver first releases the subsystem reset, loads the firmware image
> > and then releases the local reset to let the M4F processing core run.
> > 
> > Signed-off-by: Martyn Welch 
> > Signed-off-by: Hari Nagalla 
> > Signed-off-by: Andrew Davis 
> > ---
> >  drivers/remoteproc/Kconfig   |  13 +
> >  drivers/remoteproc/Makefile  |   1 +
> >  drivers/remoteproc/ti_k3_m4_remoteproc.c | 667 +++
> >  3 files changed, 681 insertions(+)
> >  create mode 100644 drivers/remoteproc/ti_k3_m4_remoteproc.c
> > 
> > diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> > index dda2ada215b7c..0f0862e20a932 100644
> > --- a/drivers/remoteproc/Kconfig
> > +++ b/drivers/remoteproc/Kconfig
> > @@ -340,6 +340,19 @@ config TI_K3_DSP_REMOTEPROC
> >   It's safe to say N here if you're not interested in utilizing
> >   the DSP slave processors.
> >  
> > +config TI_K3_M4_REMOTEPROC
> > +   tristate "TI K3 M4 remoteproc support"
> > +   depends on ARCH_K3 || COMPILE_TEST
> > +   select MAILBOX
> > +   select OMAP2PLUS_MBOX
> > +   help
> > + Say m here to support TI's M4 remote processor subsystems
> > + on various TI K3 family of SoCs through the remote processor
> > + framework.
> > +
> > + It's safe to say N here if you're not interested in utilizing
> > + a remote processor.
> > +
> >  config TI_K3_R5_REMOTEPROC
> > tristate "TI K3 R5 remoteproc support"
> > depends on ARCH_K3
> > diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> > index 91314a9b43cef..5ff4e2fee4abd 100644
> > --- a/drivers/remoteproc/Makefile
> > +++ b/drivers/remoteproc/Makefile
> > @@ -37,5 +37,6 @@ obj-$(CONFIG_ST_REMOTEPROC)   += 
> > st_remoteproc.o
> >  obj-$(CONFIG_ST_SLIM_REMOTEPROC)   += st_slim_rproc.o
> >  obj-$(CONFIG_STM32_RPROC)  += stm32_rproc.o
> >  obj-$(CONFIG_TI_K3_DSP_REMOTEPROC) += ti_k3_dsp_remoteproc.o
> > +obj-$(CONFIG_TI_K3_M4_REMOTEPROC)  += ti_k3_m4_remoteproc.o
> >  obj-$(CONFIG_TI_K3_R5_REMOTEPROC)  += ti_k3_r5_remoteproc.o
> >  obj-$(CONFIG_XLNX_R5_REMOTEPROC)   += xlnx_r5_remoteproc.o
> > diff --git a/drivers/remoteproc/ti_k3_m4_remoteproc.c 
> > b/drivers/remoteproc/ti_k3_m4_remoteproc.c
> > new file mode 100644
> > index 0..09f0484a90e10
> > --- /dev/null
> > +++ b/drivers/remoteproc/ti_k3_m4_remoteproc.c
> > @@ -0,0 +1,667 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * TI K3 Cortex-M4 Remote Processor(s) driver
> > + *
> > + * Copyright (C) 2021-2024 Texas Instruments Incorporated - 
> > https://www.ti.com/
> > + * Hari Nagalla 
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "omap_remoteproc.h"
> > +#include "remoteproc_internal.h"
> > +#include "ti_sci_proc.h"
> > +
> > +#define K3_M4_IRAM_DEV_ADDR 0x0
> > +#define K3_M4_DRAM_DEV_ADDR 0x3
> > +
> > +/**
> > + * struct k3_m4_rproc_mem - internal memory structure
> > + * @cpu_addr: MPU virtual address of the memory

Re: [PATCH v11 3/9] remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem

[Mathieu Poirier]

Hi,

On Fri, Aug 02, 2024 at 10:21:03AM -0500, Andrew Davis wrote:
> From: Martyn Welch 
> 
> The AM62x and AM64x SoCs of the TI K3 family has a Cortex M4F core in
> the MCU domain. This core is typically used for safety applications in a
> stand alone mode. However, some application (non safety related) may
> want to use the M4F core as a generic remote processor with IPC to the
> host processor. The M4F core has internal IRAM and DRAM memories and are
> exposed to the system bus for code and data loading.
> 
> A remote processor driver is added to support this subsystem, including
> being able to load and boot the M4F core. Loading includes to M4F
> internal memories and predefined external code/data memories. The
> carve outs for external contiguous memory is defined in the M4F device
> node and should match with the external memory declarations in the M4F
> image binary. The M4F subsystem has two resets. One reset is for the
> entire subsystem i.e including the internal memories and the other, a
> local reset is only for the M4F processing core. When loading the image,
> the driver first releases the subsystem reset, loads the firmware image
> and then releases the local reset to let the M4F processing core run.
> 
> Signed-off-by: Martyn Welch 
> Signed-off-by: Hari Nagalla 
> Signed-off-by: Andrew Davis 
> ---
>  drivers/remoteproc/Kconfig   |  13 +
>  drivers/remoteproc/Makefile  |   1 +
>  drivers/remoteproc/ti_k3_m4_remoteproc.c | 667 +++
>  3 files changed, 681 insertions(+)
>  create mode 100644 drivers/remoteproc/ti_k3_m4_remoteproc.c
> 
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index dda2ada215b7c..0f0862e20a932 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -340,6 +340,19 @@ config TI_K3_DSP_REMOTEPROC
> It's safe to say N here if you're not interested in utilizing
> the DSP slave processors.
>  
> +config TI_K3_M4_REMOTEPROC
> + tristate "TI K3 M4 remoteproc support"
> + depends on ARCH_K3 || COMPILE_TEST
> + select MAILBOX
> + select OMAP2PLUS_MBOX
> + help
> +   Say m here to support TI's M4 remote processor subsystems
> +   on various TI K3 family of SoCs through the remote processor
> +   framework.
> +
> +   It's safe to say N here if you're not interested in utilizing
> +   a remote processor.
> +
>  config TI_K3_R5_REMOTEPROC
>   tristate "TI K3 R5 remoteproc support"
>   depends on ARCH_K3
> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> index 91314a9b43cef..5ff4e2fee4abd 100644
> --- a/drivers/remoteproc/Makefile
> +++ b/drivers/remoteproc/Makefile
> @@ -37,5 +37,6 @@ obj-$(CONFIG_ST_REMOTEPROC) += st_remoteproc.o
>  obj-$(CONFIG_ST_SLIM_REMOTEPROC) += st_slim_rproc.o
>  obj-$(CONFIG_STM32_RPROC)+= stm32_rproc.o
>  obj-$(CONFIG_TI_K3_DSP_REMOTEPROC)   += ti_k3_dsp_remoteproc.o
> +obj-$(CONFIG_TI_K3_M4_REMOTEPROC)+= ti_k3_m4_remoteproc.o
>  obj-$(CONFIG_TI_K3_R5_REMOTEPROC)+= ti_k3_r5_remoteproc.o
>  obj-$(CONFIG_XLNX_R5_REMOTEPROC) += xlnx_r5_remoteproc.o
> diff --git a/drivers/remoteproc/ti_k3_m4_remoteproc.c 
> b/drivers/remoteproc/ti_k3_m4_remoteproc.c
> new file mode 100644
> index 0..09f0484a90e10
> --- /dev/null
> +++ b/drivers/remoteproc/ti_k3_m4_remoteproc.c
> @@ -0,0 +1,667 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * TI K3 Cortex-M4 Remote Processor(s) driver
> + *
> + * Copyright (C) 2021-2024 Texas Instruments Incorporated - 
> https://www.ti.com/
> + *   Hari Nagalla 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "omap_remoteproc.h"
> +#include "remoteproc_internal.h"
> +#include "ti_sci_proc.h"
> +
> +#define K3_M4_IRAM_DEV_ADDR 0x0
> +#define K3_M4_DRAM_DEV_ADDR 0x3
> +
> +/**
> + * struct k3_m4_rproc_mem - internal memory structure
> + * @cpu_addr: MPU virtual address of the memory region
> + * @bus_addr: Bus address used to access the memory region
> + * @dev_addr: Device address of the memory region from remote processor view
> + * @size: Size of the memory region
> + */
> +struct k3_m4_rproc_mem {
> + void __iomem *cpu_addr;
> + phys_addr_t bus_addr;
> + u32 dev_addr;
> + size_t size;
> +};
> +
> +/**
> + * struct k3_m4_rproc_mem_data - memory definitions for a remote processor
> + * @name: name for this memory entry
> + * @dev_addr: device address for the memory entry
> + */
> +struct k3_m4_rproc_mem_data {
> + const char *name;
> + const u32 dev_addr;
> +};
> +
> +/**
> + * struct k3_m4_rproc - k3 remote processor driver structure
> + * @dev: cached device pointer
> + * @mem: internal memory regions data
> + * @num_mems: number of internal memory regions
> + * @rmem: reserved memory regions data
> + * @num_rmems: number of reserved memory regions
> + * @reset: reset control han

Re: [PATCH v4 3/3] remoteproc: k3-dsp: Acquire mailbox handle during probe routine

[Mathieu Poirier]

On Thu, Aug 08, 2024 at 01:11:27PM +0530, Beleswar Padhi wrote:
> Acquire the mailbox handle during device probe and do not release handle
> in stop/detach routine or error paths. This removes the redundant
> requests for mbox handle later during rproc start/attach. This also
> allows to defer remoteproc driver's probe if mailbox is not probed yet.
> 
> Signed-off-by: Beleswar Padhi 
> Acked-by: Andrew Davis 
> ---
>  drivers/remoteproc/ti_k3_dsp_remoteproc.c | 80 +--
>  1 file changed, 30 insertions(+), 50 deletions(-)
> 
> diff --git a/drivers/remoteproc/ti_k3_dsp_remoteproc.c 
> b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
> index a22d41689a7d..9009367e2891 100644
> --- a/drivers/remoteproc/ti_k3_dsp_remoteproc.c
> +++ b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
> @@ -115,6 +115,10 @@ static void k3_dsp_rproc_mbox_callback(struct 
> mbox_client *client, void *data)
>   const char *name = kproc->rproc->name;
>   u32 msg = omap_mbox_message(data);
>  
> + /* Do not forward messages from a detached core */
> + if (kproc->rproc->state == RPROC_DETACHED)
> + return;
> +
>   dev_dbg(dev, "mbox msg: 0x%x\n", msg);
>  
>   switch (msg) {
> @@ -155,6 +159,10 @@ static void k3_dsp_rproc_kick(struct rproc *rproc, int 
> vqid)
>   mbox_msg_t msg = (mbox_msg_t)vqid;
>   int ret;
>  
> + /* Do not forward messages to a detached core */
> + if (kproc->rproc->state == RPROC_DETACHED)
> + return;
> +
>   /* send the index of the triggered virtqueue in the mailbox payload */
>   ret = mbox_send_message(kproc->mbox, (void *)msg);
>   if (ret < 0)
> @@ -230,12 +238,9 @@ static int k3_dsp_rproc_request_mbox(struct rproc *rproc)
>   client->knows_txdone = false;
>  
>   kproc->mbox = mbox_request_channel(client, 0);
> - if (IS_ERR(kproc->mbox)) {
> - ret = -EBUSY;
> - dev_err(dev, "mbox_request_channel failed: %ld\n",
> - PTR_ERR(kproc->mbox));
> - return ret;
> - }
> + if (IS_ERR(kproc->mbox))
> + return dev_err_probe(dev, PTR_ERR(kproc->mbox),
> +  "mbox_request_channel failed\n");
>  
>   /*
>* Ping the remote processor, this is only for sanity-sake for now;
> @@ -315,32 +320,23 @@ static int k3_dsp_rproc_start(struct rproc *rproc)
>   u32 boot_addr;
>   int ret;
>  
> - ret = k3_dsp_rproc_request_mbox(rproc);
> - if (ret)
> - return ret;
> -
>   boot_addr = rproc->bootaddr;
>   if (boot_addr & (kproc->data->boot_align_addr - 1)) {
>   dev_err(dev, "invalid boot address 0x%x, must be aligned on a 
> 0x%x boundary\n",
>   boot_addr, kproc->data->boot_align_addr);
> - ret = -EINVAL;
> - goto put_mbox;
> + return -EINVAL;
>   }
>  
>   dev_dbg(dev, "booting DSP core using boot addr = 0x%x\n", boot_addr);
>   ret = ti_sci_proc_set_config(kproc->tsp, boot_addr, 0, 0);
>   if (ret)
> - goto put_mbox;
> + return ret;
>  
>   ret = k3_dsp_rproc_release(kproc);
>   if (ret)
> - goto put_mbox;
> + return ret;
>  
>   return 0;
> -
> -put_mbox:
> - mbox_free_channel(kproc->mbox);
> - return ret;
>  }
>  
>  /*
> @@ -353,8 +349,6 @@ static int k3_dsp_rproc_stop(struct rproc *rproc)
>  {
>   struct k3_dsp_rproc *kproc = rproc->priv;
>  
> - mbox_free_channel(kproc->mbox);
> -
>   k3_dsp_rproc_reset(kproc);
>  
>   return 0;
> @@ -363,42 +357,22 @@ static int k3_dsp_rproc_stop(struct rproc *rproc)
>  /*
>   * Attach to a running DSP remote processor (IPC-only mode)
>   *
> - * This rproc attach callback only needs to request the mailbox, the remote
> - * processor is already booted, so there is no need to issue any TI-SCI
> - * commands to boot the DSP core. This callback is invoked only in IPC-only
> - * mode.
> + * This rproc attach callback is a NOP. The remote processor is already 
> booted,
> + * and all required resources have been acquired during probe routine, so 
> there
> + * is no need to issue any TI-SCI commands to boot the DSP core. This 
> callback
> + * is invoked only in IPC-only mode and exists because rproc_validate() 
> checks
> + * for its existence.
>   */
> -static int k3_dsp_rproc_attach(struct rproc *rproc)
> -{
> - struct k3_dsp_rproc *kproc = rproc->priv;
> - struct device *dev = kproc->dev;
> - int ret;
> -
> - ret = k3_dsp_rproc_request_mbox(rproc);
> - if (ret)
> - return ret;
> -
> - dev_info(dev, "DSP initialized in IPC-only mode\n");
> - return 0;
> -}
> +static int k3_dsp_rproc_attach(struct rproc *rproc) { return 0; }
>  
>  /*
>   * Detach from a running DSP remote processor (IPC-only mode)
>   *
> - * This rproc detach callback performs the opposite operation to attach 
> callback
> - * and only needs to release the mailbox, the DSP core

Re: [PATCH v4 2/3] remoteproc: k3-r5: Acquire mailbox handle during probe routine

[Mathieu Poirier]

Hi Beleswar,

On Thu, Aug 08, 2024 at 01:11:26PM +0530, Beleswar Padhi wrote:
> Acquire the mailbox handle during device probe and do not release handle
> in stop/detach routine or error paths. This removes the redundant
> requests for mbox handle later during rproc start/attach. This also
> allows to defer remoteproc driver's probe if mailbox is not probed yet.
> 
> Signed-off-by: Beleswar Padhi 
> ---
>  drivers/remoteproc/ti_k3_r5_remoteproc.c | 78 +---
>  1 file changed, 30 insertions(+), 48 deletions(-)
> 
> diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c 
> b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> index 57067308b3c0..8a63a9360c0f 100644
> --- a/drivers/remoteproc/ti_k3_r5_remoteproc.c
> +++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> @@ -194,6 +194,10 @@ static void k3_r5_rproc_mbox_callback(struct mbox_client 
> *client, void *data)
>   const char *name = kproc->rproc->name;
>   u32 msg = omap_mbox_message(data);
>  
> + /* Do not forward message from a detached core */
> + if (kproc->rproc->state == RPROC_DETACHED)
> + return;
> +
>   dev_dbg(dev, "mbox msg: 0x%x\n", msg);
>  
>   switch (msg) {
> @@ -229,6 +233,10 @@ static void k3_r5_rproc_kick(struct rproc *rproc, int 
> vqid)
>   mbox_msg_t msg = (mbox_msg_t)vqid;
>   int ret;
>  
> + /* Do not forward message to a detached core */
> + if (kproc->rproc->state == RPROC_DETACHED)
> + return;
> +
>   /* send the index of the triggered virtqueue in the mailbox payload */
>   ret = mbox_send_message(kproc->mbox, (void *)msg);
>   if (ret < 0)
> @@ -399,12 +407,9 @@ static int k3_r5_rproc_request_mbox(struct rproc *rproc)
>   client->knows_txdone = false;
>  
>   kproc->mbox = mbox_request_channel(client, 0);
> - if (IS_ERR(kproc->mbox)) {
> - ret = -EBUSY;
> - dev_err(dev, "mbox_request_channel failed: %ld\n",
> - PTR_ERR(kproc->mbox));
> - return ret;
> - }
> + if (IS_ERR(kproc->mbox))
> + return dev_err_probe(dev, PTR_ERR(kproc->mbox),
> +  "mbox_request_channel failed\n");
>  
>   /*
>* Ping the remote processor, this is only for sanity-sake for now;
> @@ -552,10 +557,6 @@ static int k3_r5_rproc_start(struct rproc *rproc)
>   u32 boot_addr;
>   int ret;
>  
> - ret = k3_r5_rproc_request_mbox(rproc);
> - if (ret)
> - return ret;
> -
>   boot_addr = rproc->bootaddr;
>   /* TODO: add boot_addr sanity checking */
>   dev_dbg(dev, "booting R5F core using boot addr = 0x%x\n", boot_addr);
> @@ -564,7 +565,7 @@ static int k3_r5_rproc_start(struct rproc *rproc)
>   core = kproc->core;
>   ret = ti_sci_proc_set_config(core->tsp, boot_addr, 0, 0);
>   if (ret)
> - goto put_mbox;
> + return ret;
>  
>   /* unhalt/run all applicable cores */
>   if (cluster->mode == CLUSTER_MODE_LOCKSTEP) {
> @@ -580,13 +581,12 @@ static int k3_r5_rproc_start(struct rproc *rproc)
>   if (core != core0 && core0->rproc->state == RPROC_OFFLINE) {
>   dev_err(dev, "%s: can not start core 1 before core 0\n",
>   __func__);
> - ret = -EPERM;
> - goto put_mbox;
> + return -EPERM;
>   }
>  
>   ret = k3_r5_core_run(core);
>   if (ret)
> - goto put_mbox;
> + return ret;
>   }
>  
>   return 0;
> @@ -596,8 +596,6 @@ static int k3_r5_rproc_start(struct rproc *rproc)
>   if (k3_r5_core_halt(core))
>   dev_warn(core->dev, "core halt back failed\n");
>   }
> -put_mbox:
> - mbox_free_channel(kproc->mbox);
>   return ret;
>  }
>  
> @@ -658,8 +656,6 @@ static int k3_r5_rproc_stop(struct rproc *rproc)
>   goto out;
>   }
>  
> - mbox_free_channel(kproc->mbox);
> -
>   return 0;
>  
>  unroll_core_halt:
> @@ -674,42 +670,22 @@ static int k3_r5_rproc_stop(struct rproc *rproc)
>  /*
>   * Attach to a running R5F remote processor (IPC-only mode)
>   *
> - * The R5F attach callback only needs to request the mailbox, the remote
> - * processor is already booted, so there is no need to issue any TI-SCI
> - * commands to boot the R5F cores in IPC-only mode. This callback is invoked
> - * only in IPC-only mode.
> + * The R5F attach callback is a NOP. The remote processor is already booted, 
> and
> + * all required resources have been acquired during probe routine, so there 
> is
> + * no need to issue any TI-SCI commands to boot the R5F cores in IPC-only 
> mode.
> + * This callback is invoked only in IPC-only mode and exists because
> + * rproc_validate() checks for its existence.

Excellent documentation.

>   */
> -static int k3_r5_rproc_attach(struct rproc *rproc)
> -{
> - struct k3_r5_rproc *kproc = 

Re: [PATCH v2 2/2] remoteproc: imx_rproc: handle system off for i.MX7ULP

[Mathieu Poirier]

On Fri, Aug 02, 2024 at 04:59:45AM +, Peng Fan wrote:
> > Subject: Re: [PATCH v2 2/2] remoteproc: imx_rproc: handle system off
> > for i.MX7ULP
> > 
> > On Tue, Jul 30, 2024 at 08:06:22AM +, Peng Fan wrote:
> > > > Subject: Re: [PATCH v2 2/2] remoteproc: imx_rproc: handle system
> > off
> > > > for i.MX7ULP
> > > >
> > > > On Fri, Jul 19, 2024 at 04:49:04PM +0800, Peng Fan (OSS) wrote:
> > > > > From: Peng Fan 
> > > > >
> > > > > The i.MX7ULP Cortex-A7 is under control of Cortex-M4. The
> > > > i.MX7ULP
> > > > > Linux poweroff and restart rely on rpmsg driver to send a message
> > > > > to
> > > > > Cortex-M4 firmware. Then Cortex-A7 could poweroff or restart by
> > > > > Cortex-M4 to configure the i.MX7ULP power controller properly.
> > > > >
> > > > > However the reboot and restart kernel common code use atomic
> > > > notifier,
> > > > > so with blocking tx mailbox will trigger kernel dump, because of
> > > > > blocking mailbox will use wait_for_completion_timeout. In such
> > > > > case, linux no need to wait for completion.
> > > > >
> > > > > Current patch is to use non-blocking tx mailbox channel when
> > > > > system
> > > > is
> > > > > going to poweroff or restart.
> > > > >
> > > > > Signed-off-by: Peng Fan 
> > > > > ---
> > > > >  drivers/remoteproc/imx_rproc.c | 36
> > > > > 
> > > > >  1 file changed, 36 insertions(+)
> > > > >
> > > > > diff --git a/drivers/remoteproc/imx_rproc.c
> > > > > b/drivers/remoteproc/imx_rproc.c index
> > > > 01cf1dfb2e87..e1abf110abc9
> > > > > 100644
> > > > > --- a/drivers/remoteproc/imx_rproc.c
> > > > > +++ b/drivers/remoteproc/imx_rproc.c
> > > > > @@ -18,6 +18,7 @@
> > > > >  #include   #include
> > > > >   #include 
> > > > > +#include 
> > > > >  #include 
> > > > >  #include 
> > > > >  #include 
> > > > > @@ -114,6 +115,7 @@ struct imx_rproc {
> > > > >   u32 entry;  /* cpu start
> > > > address */
> > > > >   u32 core_index;
> > > > >   struct dev_pm_domain_list   *pd_list;
> > > > > + struct sys_off_data data;
> > > >
> > > > What is this for?  I don't see it used in this patch.
> > >
> > > Oh, it was added when I was developing this feature, but in the end
> > > this seems not needed.
> > >
> > > >
> > > > >  };
> > > > >
> > > > >  static const struct imx_rproc_att imx_rproc_att_imx93[] = { @@
> > > > > -1050,6 +1052,22 @@ static int imx_rproc_clk_enable(struct
> > > > imx_rproc *priv)
> > > > >   return 0;
> > > > >  }
> > > > >
> > > > > +static int imx_rproc_sys_off_handler(struct sys_off_data *data) {
> > > > > + struct rproc *rproc = data->cb_data;
> > > > > + int ret;
> > > > > +
> > > > > + imx_rproc_free_mbox(rproc);
> > > > > +
> > > > > + ret = imx_rproc_xtr_mbox_init(rproc, false);
> > > > > + if (ret) {
> > > > > + dev_err(&rproc->dev, "Failed to request non-blocking
> > > > mbox\n");
> > > > > + return NOTIFY_BAD;
> > > > > + }
> > > > > +
> > > > > + return NOTIFY_DONE;
> > > > > +}
> > > > > +
> > > > >  static int imx_rproc_probe(struct platform_device *pdev)  {
> > > > >   struct device *dev = &pdev->dev; @@ -1104,6 +1122,24 @@
> > static
> > > > > int imx_rproc_probe(struct
> > > > platform_device *pdev)
> > > > >   if (rproc->state != RPROC_DETACHED)
> > > > >   rproc->auto_boot = of_property_read_bool(np,
> > > > "fsl,auto-boot");
> > > > >
> > > > > + if (of_device_is_compatible(dev->of_node, "fsl,imx7ulp-cm4"))
> > > > {
> > > > > + ret = devm_register_sys_off_handler(dev,
> > > > SYS_OFF_MODE_POWER_OFF_PREPARE,
> > > > > +
> > > > SYS_OFF_PRIO_DEFAULT,
> > > > > +
> > > > imx_rproc_sys_off_handler, rproc);
> > > >
> > > > Why does the mailbox needs to be set up again when the system is
> > > > going down...
> > >
> > > As wrote in commit message:
> > > "i.MX7ULP Linux poweroff and restart rely on rpmsg driver to send a
> > > message," so need to set up mailbox in non-blocking way to send a
> > > message to M4 side.
> > >
> > > >
> > > > > + if (ret) {
> > > > > + dev_err(dev, "register power off handler
> > > > failure\n");
> > > > > + goto err_put_clk;
> > > > > + }
> > > > > +
> > > > > + ret = devm_register_sys_off_handler(dev,
> > > > SYS_OFF_MODE_RESTART_PREPARE,
> > > > > +
> > > > SYS_OFF_PRIO_DEFAULT,
> > > > > +
> > > > imx_rproc_sys_off_handler, rproc);
> > > >
> > > > ... and why does it need to be free'd when the system is going up?
> > >
> > >
> > > Sorry, I not get your point. The free is in imx_rproc_sys_off_handler.
> > > During system booting, the mailbox is not freed.
> > 
> > Why is the same operation done at both startup and shutdown - that is
> > not clear.
> 
> The below commit shows request/free done in startup and shutdown.
> Hope this explains what you ask.

Unfortunately it doesn't.  I just spent 

Re: [PATCH 6/6] remoteproc: imx_rproc: handle system off for i.MX7ULP

[Mathieu Poirier]

On Thu, Aug 08, 2024 at 02:56:20AM +, Peng Fan wrote:
> > Subject: Re: [PATCH 6/6] remoteproc: imx_rproc: handle system off for
> > i.MX7ULP
> > 
> > On Fri, Jul 12, 2024 at 04:34:59PM +0800, Peng Fan (OSS) wrote:
> > > From: Peng Fan 
> > >
> > > The i.MX7ULP Cortex-A7 is under control of Cortex-M4. The
> > i.MX7ULP
> > > Linux poweroff and restart rely on rpmsg driver to send a message to
> > > Cortex-M4 firmware. Then Cortex-A7 could poweroff or restart by
> > > Cortex-M4 to configure the i.MX7ULP power controller properly.
> > >
> > > However the reboot and restart kernel common code use atomic
> > notifier,
> > > so with blocking tx mailbox will trigger kernel dump, because of
> > > blocking mailbox will use wait_for_completion_timeout. In such case,
> > > linux no need to wait for completion.
> > >
> > > Current patch is to use non-blocking tx mailbox channel when system
> > is
> > > going to poweroff or restart.
> > >
> > > Reviewed-by: Jacky Bai 
> > > Signed-off-by: Peng Fan 
> > > ---
> > >  drivers/remoteproc/imx_rproc.c | 36
> > > 
> > >  1 file changed, 36 insertions(+)
> > >
> > > diff --git a/drivers/remoteproc/imx_rproc.c
> > > b/drivers/remoteproc/imx_rproc.c index
> > 01cf1dfb2e87..e1abf110abc9
> > > 100644
> > > --- a/drivers/remoteproc/imx_rproc.c
> > > +++ b/drivers/remoteproc/imx_rproc.c
> > > @@ -18,6 +18,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >  #include 
> > >  #include 
> > >  #include 
> > > @@ -114,6 +115,7 @@ struct imx_rproc {
> > >   u32 entry;  /* cpu start
> > address */
> > >   u32 core_index;
> > >   struct dev_pm_domain_list   *pd_list;
> > > + struct sys_off_data data;
> > >  };
> > >
> > >  static const struct imx_rproc_att imx_rproc_att_imx93[] = { @@
> > > -1050,6 +1052,22 @@ static int imx_rproc_clk_enable(struct
> > imx_rproc *priv)
> > >   return 0;
> > >  }
> > >
> > > +static int imx_rproc_sys_off_handler(struct sys_off_data *data) {
> > > + struct rproc *rproc = data->cb_data;
> > > + int ret;
> > > +
> > > + imx_rproc_free_mbox(rproc);
> > > +
> > > + ret = imx_rproc_xtr_mbox_init(rproc, false);
> > > + if (ret) {
> > > + dev_err(&rproc->dev, "Failed to request non-blocking
> > mbox\n");
> > > + return NOTIFY_BAD;
> > > + }
> > > +
> > > + return NOTIFY_DONE;
> > > +}
> > > +
> > >  static int imx_rproc_probe(struct platform_device *pdev)  {
> > >   struct device *dev = &pdev->dev;
> > > @@ -1104,6 +1122,24 @@ static int imx_rproc_probe(struct
> > platform_device *pdev)
> > >   if (rproc->state != RPROC_DETACHED)
> > >   rproc->auto_boot = of_property_read_bool(np,
> > "fsl,auto-boot");
> > >
> > > + if (of_device_is_compatible(dev->of_node, "fsl,imx7ulp-cm4"))
> > {
> > 
> > I don't suggest check compatible string. It'd better add a field  in
> > imx_rproc_dcfg, such as need_sys_off
> > 
> > if (dcfg->need_sys_off) {
> > ...
> > }
> > 
> > If there are new compatible string added, just need set need_sys_off to
> > true in driver data.
> 
> Could we delay the change when there is really new chips need this?
> The downstream commit time is " Date:   Tue Dec 6 17:10:14 2022",
> In the past days, I not see other platforms require this.
> 
> Mathieu, which do you prefer? add need_sys_off or keep current
> approach?
>

This driver is already making extensive use of device data and as such suggest
to continue with that method.

> Thanks,
> Peng.
> 
> > 
> > Frank
> > 
> > > + ret = devm_register_sys_off_handler(dev,
> > SYS_OFF_MODE_POWER_OFF_PREPARE,
> > > +
> > SYS_OFF_PRIO_DEFAULT,
> > > +
> > imx_rproc_sys_off_handler, rproc);
> > > + if (ret) {
> > > + dev_err(dev, "register power off handler
> > failure\n");
> > > + goto err_put_clk;
> > > + }
> > > +
> > > + ret = devm_register_sys_off_handler(dev,
> > SYS_OFF_MODE_RESTART_PREPARE,
> > > +
> > SYS_OFF_PRIO_DEFAULT,
> > > +
> > imx_rproc_sys_off_handler, rproc);
> > > + if (ret) {
> > > + dev_err(dev, "register restart handler
> > failure\n");
> > > + goto err_put_clk;
> > > + }
> > > + }
> > > +
> > >   ret = rproc_add(rproc);
> > >   if (ret) {
> > >   dev_err(dev, "rproc_add failed\n");
> > >
> > > --
> > > 2.37.1
> > >

Re: [PATCH 3/7] remoteproc: keystone: Use devm action to release reserved memory

[Mathieu Poirier]

On Fri, Aug 02, 2024 at 01:22:56PM -0500, Andrew Davis wrote:
> This helps prevent mistakes like freeing out of order in cleanup functions
> and forgetting to free on error paths.
> 
> Signed-off-by: Andrew Davis 
> ---
>  drivers/remoteproc/keystone_remoteproc.c | 17 ++---
>  1 file changed, 14 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/remoteproc/keystone_remoteproc.c 
> b/drivers/remoteproc/keystone_remoteproc.c
> index 8f0f7a4cfef26..033e573544fef 100644
> --- a/drivers/remoteproc/keystone_remoteproc.c
> +++ b/drivers/remoteproc/keystone_remoteproc.c
> @@ -358,6 +358,13 @@ static int keystone_rproc_of_get_dev_syscon(struct 
> platform_device *pdev,
>   return 0;
>  }
>  
> +static void keystone_rproc_mem_release(void *data)
> +{
> + struct device *dev = data;
> +
> + of_reserved_mem_device_release(dev);
> +}
> +
>  static int keystone_rproc_probe(struct platform_device *pdev)
>  {
>   struct device *dev = &pdev->dev;
> @@ -434,8 +441,14 @@ static int keystone_rproc_probe(struct platform_device 
> *pdev)
>   goto disable_clk;
>   }
>  
> - if (of_reserved_mem_device_init(dev))
> + ret = of_reserved_mem_device_init(dev);
> + if (ret) {
>   dev_warn(dev, "device does not have specific CMA pool\n");
> + } else {
> + ret = devm_add_action_or_reset(dev, keystone_rproc_mem_release, 
> dev);
> + if (ret)
> + return ret;

It gets sorted out in the next patches but we still need to "goto disable_clk"
to avoid git-bisect problems.

I have applied the first two patches of this set so no need to resend them.

Thanks,
Mathieu

> + }
>  
>   /* ensure the DSP is in reset before loading firmware */
>   ret = reset_control_status(ksproc->reset);
> @@ -459,7 +472,6 @@ static int keystone_rproc_probe(struct platform_device 
> *pdev)
>   return 0;
>  
>  release_mem:
> - of_reserved_mem_device_release(dev);
>   gpiod_put(ksproc->kick_gpio);
>  disable_clk:
>   pm_runtime_put_sync(dev);
> @@ -476,7 +488,6 @@ static void keystone_rproc_remove(struct platform_device 
> *pdev)
>   gpiod_put(ksproc->kick_gpio);
>   pm_runtime_put_sync(&pdev->dev);
>   pm_runtime_disable(&pdev->dev);
> - of_reserved_mem_device_release(&pdev->dev);
>  }
>  
>  static const struct of_device_id keystone_rproc_of_match[] = {
> -- 
> 2.39.2
> 

Re: [PATCH] dt-bindings: remoteproc: xlnx,zynqmp-r5fss: add missing "additionalProperties" on child nodes

[Mathieu Poirier]

On Sun, Aug 11, 2024 at 05:34:38PM +0200, Krzysztof Kozlowski wrote:
> All nodes need an explicit additionalProperties or unevaluatedProperties
> unless a $ref has one that's false.  Add missing additionalProperties
> to fix dt_binding_check warning:
> 
>   xlnx,zynqmp-r5fss.yaml: ^r(.*)@[0-9a-f]+$: Missing 
> additionalProperties/unevaluatedProperties constraint
> 
> Fixes: 9e1b2a0757d0 ("dt-bindings: remoteproc: Add Tightly Coupled Memory 
> (TCM) bindings")
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  .../devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml| 1 +
>  1 file changed, 1 insertion(+)
>

Applied.

Thanks,
Mathieu

> diff --git 
> a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml 
> b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
> index 6f13da11f593..ee63c03949c9 100644
> --- a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
> @@ -62,6 +62,7 @@ properties:
>  patternProperties:
>"^r(.*)@[0-9a-f]+$":
>  type: object
> +additionalProperties: false
>  description: |
>The RPU is located in the Low Power Domain of the Processor Subsystem.
>Each processor includes separate L1 instruction and data caches and
> -- 
> 2.43.0
> 

Re: [PATCH] remoteproc: Use of_property_present()

[Mathieu Poirier]

On Wed, Jul 31, 2024 at 01:12:45PM -0600, Rob Herring (Arm) wrote:
> Use of_property_present() to test for property presence rather than
> of_(find|get)_property(). This is part of a larger effort to remove
> callers of of_find_property() and similar functions. of_find_property()
> leaks the DT struct property and data pointers which is a problem for
> dynamically allocated nodes which may be freed.
> 
> Signed-off-by: Rob Herring (Arm) 
> ---
>  drivers/remoteproc/imx_dsp_rproc.c  | 2 +-
>  drivers/remoteproc/imx_rproc.c  | 2 +-
>  drivers/remoteproc/xlnx_r5_remoteproc.c | 6 +++---
>  3 files changed, 5 insertions(+), 5 deletions(-)
>

I have applied this patch.

Thanks,
Mathieu

> diff --git a/drivers/remoteproc/imx_dsp_rproc.c 
> b/drivers/remoteproc/imx_dsp_rproc.c
> index 087506e21508..376187ad5754 100644
> --- a/drivers/remoteproc/imx_dsp_rproc.c
> +++ b/drivers/remoteproc/imx_dsp_rproc.c
> @@ -509,7 +509,7 @@ static int imx_dsp_rproc_mbox_alloc(struct imx_dsp_rproc 
> *priv)
>   struct mbox_client *cl;
>   int ret;
>  
> - if (!of_get_property(dev->of_node, "mbox-names", NULL))
> + if (!of_property_present(dev->of_node, "mbox-names"))
>   return 0;
>  
>   cl = &priv->cl;
> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index 144c8e9a642e..8d7ecc809c67 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -807,7 +807,7 @@ static int imx_rproc_xtr_mbox_init(struct rproc *rproc)
>   if (priv->tx_ch && priv->rx_ch)
>   return 0;
>  
> - if (!of_get_property(dev->of_node, "mbox-names", NULL))
> + if (!of_property_present(dev->of_node, "mbox-names"))
>   return 0;
>  
>   cl = &priv->cl;
> diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c 
> b/drivers/remoteproc/xlnx_r5_remoteproc.c
> index 596f3ffb8935..2cea97c746fd 100644
> --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
> +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
> @@ -1059,7 +1059,7 @@ static int zynqmp_r5_core_init(struct zynqmp_r5_cluster 
> *cluster,
>   r5_core = cluster->r5_cores[0];
>  
>   /* Maintain backward compatibility for zynqmp by using hardcode TCM 
> address. */
> - if (of_find_property(r5_core->np, "reg", NULL))
> + if (of_property_present(r5_core->np, "reg"))
>   ret = zynqmp_r5_get_tcm_node_from_dt(cluster);
>   else if (device_is_compatible(dev, "xlnx,zynqmp-r5fss"))
>   ret = zynqmp_r5_get_tcm_node(cluster);
> @@ -1086,7 +1086,7 @@ static int zynqmp_r5_core_init(struct zynqmp_r5_cluster 
> *cluster,
>   return ret;
>   }
>  
> - if (of_find_property(dev_of_node(dev), "xlnx,tcm-mode", NULL) ||
> + if (of_property_present(dev_of_node(dev), "xlnx,tcm-mode") ||
>   device_is_compatible(dev, "xlnx,zynqmp-r5fss")) {
>   ret = zynqmp_pm_set_tcm_config(r5_core->pm_domain_id,
>  tcm_mode);
> @@ -1147,7 +1147,7 @@ static int zynqmp_r5_cluster_init(struct 
> zynqmp_r5_cluster *cluster)
>   return -EINVAL;
>   }
>  
> - if (of_find_property(dev_node, "xlnx,tcm-mode", NULL)) {
> + if (of_property_present(dev_node, "xlnx,tcm-mode")) {
>   ret = of_property_read_u32(dev_node, "xlnx,tcm-mode", (u32 
> *)&tcm_mode);
>   if (ret)
>   return ret;
> -- 
> 2.43.0
> 

Re: [PATCH] rpmsg: char: Export alias for RPMSG ID rpmsg-raw from table

[Mathieu Poirier]

Hi Andrew,

On Mon, Jul 29, 2024 at 11:45:27AM -0500, Andrew Davis wrote:
> Module aliases are used by userspace to identify the correct module to
> load for a detected hardware. The currently supported RPMSG device IDs for
> this module include "rpmsg-raw", but the module alias is "rpmsg_chrdev".
> 
> Use the helper macro MODULE_DEVICE_TABLE(rpmsg) to export the correct
> supported IDs. And while here, to keep backwards compatibility we also add
> the other ID "rpmsg_chrdev" so that it is also still exported as an alias.
> 
> This has the side benefit of adding support for some legacy firmware
> which still uses the original "rpmsg_chrdev" ID. This was the ID used for
> this driver before it was upstreamed (as reflected by the module alias).
> 
> Signed-off-by: Andrew Davis 
> ---
>  drivers/rpmsg/rpmsg_char.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/rpmsg/rpmsg_char.c b/drivers/rpmsg/rpmsg_char.c
> index eec7642d26863..96fcdd2d7093c 100644
> --- a/drivers/rpmsg/rpmsg_char.c
> +++ b/drivers/rpmsg/rpmsg_char.c
> @@ -522,8 +522,10 @@ static void rpmsg_chrdev_remove(struct rpmsg_device 
> *rpdev)
>  
>  static struct rpmsg_device_id rpmsg_chrdev_id_table[] = {
>   { .name = "rpmsg-raw" },
> + { .name = "rpmsg_chrdev" },
>   { },
>  };
> +MODULE_DEVICE_TABLE(rpmsg, rpmsg_chrdev_id_table);

So you want to be able to do both "modprobe rpmsg-raw" and "modprobe
rpmsg_chrdev" ?

I'm not sure to get the aim of your patch and will need a little more details.

Thanks,
Mathieu

>  
>  static struct rpmsg_driver rpmsg_chrdev_driver = {
>   .probe = rpmsg_chrdev_probe,
> @@ -565,6 +567,5 @@ static void rpmsg_chrdev_exit(void)
>  }
>  module_exit(rpmsg_chrdev_exit);
>  
> -MODULE_ALIAS("rpmsg:rpmsg_chrdev");
>  MODULE_DESCRIPTION("RPMSG device interface");
>  MODULE_LICENSE("GPL v2");
> -- 
> 2.39.2
> 

Re: [PATCH v2 2/2] remoteproc: imx_rproc: handle system off for i.MX7ULP

[Mathieu Poirier]

On Tue, Jul 30, 2024 at 08:06:22AM +, Peng Fan wrote:
> > Subject: Re: [PATCH v2 2/2] remoteproc: imx_rproc: handle system off
> > for i.MX7ULP
> > 
> > On Fri, Jul 19, 2024 at 04:49:04PM +0800, Peng Fan (OSS) wrote:
> > > From: Peng Fan 
> > >
> > > The i.MX7ULP Cortex-A7 is under control of Cortex-M4. The
> > i.MX7ULP
> > > Linux poweroff and restart rely on rpmsg driver to send a message to
> > > Cortex-M4 firmware. Then Cortex-A7 could poweroff or restart by
> > > Cortex-M4 to configure the i.MX7ULP power controller properly.
> > >
> > > However the reboot and restart kernel common code use atomic
> > notifier,
> > > so with blocking tx mailbox will trigger kernel dump, because of
> > > blocking mailbox will use wait_for_completion_timeout. In such case,
> > > linux no need to wait for completion.
> > >
> > > Current patch is to use non-blocking tx mailbox channel when system
> > is
> > > going to poweroff or restart.
> > >
> > > Signed-off-by: Peng Fan 
> > > ---
> > >  drivers/remoteproc/imx_rproc.c | 36
> > > 
> > >  1 file changed, 36 insertions(+)
> > >
> > > diff --git a/drivers/remoteproc/imx_rproc.c
> > > b/drivers/remoteproc/imx_rproc.c index
> > 01cf1dfb2e87..e1abf110abc9
> > > 100644
> > > --- a/drivers/remoteproc/imx_rproc.c
> > > +++ b/drivers/remoteproc/imx_rproc.c
> > > @@ -18,6 +18,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >  #include 
> > >  #include 
> > >  #include 
> > > @@ -114,6 +115,7 @@ struct imx_rproc {
> > >   u32 entry;  /* cpu start
> > address */
> > >   u32 core_index;
> > >   struct dev_pm_domain_list   *pd_list;
> > > + struct sys_off_data data;
> > 
> > What is this for?  I don't see it used in this patch.
> 
> Oh, it was added when I was developing this feature, but in the end
> this seems not needed.
> 
> > 
> > >  };
> > >
> > >  static const struct imx_rproc_att imx_rproc_att_imx93[] = { @@
> > > -1050,6 +1052,22 @@ static int imx_rproc_clk_enable(struct
> > imx_rproc *priv)
> > >   return 0;
> > >  }
> > >
> > > +static int imx_rproc_sys_off_handler(struct sys_off_data *data) {
> > > + struct rproc *rproc = data->cb_data;
> > > + int ret;
> > > +
> > > + imx_rproc_free_mbox(rproc);
> > > +
> > > + ret = imx_rproc_xtr_mbox_init(rproc, false);
> > > + if (ret) {
> > > + dev_err(&rproc->dev, "Failed to request non-blocking
> > mbox\n");
> > > + return NOTIFY_BAD;
> > > + }
> > > +
> > > + return NOTIFY_DONE;
> > > +}
> > > +
> > >  static int imx_rproc_probe(struct platform_device *pdev)  {
> > >   struct device *dev = &pdev->dev;
> > > @@ -1104,6 +1122,24 @@ static int imx_rproc_probe(struct
> > platform_device *pdev)
> > >   if (rproc->state != RPROC_DETACHED)
> > >   rproc->auto_boot = of_property_read_bool(np,
> > "fsl,auto-boot");
> > >
> > > + if (of_device_is_compatible(dev->of_node, "fsl,imx7ulp-cm4"))
> > {
> > > + ret = devm_register_sys_off_handler(dev,
> > SYS_OFF_MODE_POWER_OFF_PREPARE,
> > > +
> > SYS_OFF_PRIO_DEFAULT,
> > > +
> > imx_rproc_sys_off_handler, rproc);
> > 
> > Why does the mailbox needs to be set up again when the system is
> > going down...
> 
> As wrote in commit message:
> "i.MX7ULP Linux poweroff and restart rely on rpmsg driver to send a
> message," so need to set up mailbox in non-blocking way to send
> a message to M4 side.
> 
> > 
> > > + if (ret) {
> > > + dev_err(dev, "register power off handler
> > failure\n");
> > > + goto err_put_clk;
> > > + }
> > > +
> > > + ret = devm_register_sys_off_handler(dev,
> > SYS_OFF_MODE_RESTART_PREPARE,
> > > +
> > SYS_OFF_PRIO_DEFAULT,
> > > +
> > imx_rproc_sys_off_handler, rproc);
> > 
> > ... and why does it need to be free'd when the system is going up?
> 
> 
> Sorry, I not get your point. The free is in imx_rproc_sys_off_handler.
> During system booting, the mailbox is not freed.

Why is the same operation done at both startup and shutdown - that is not clear.

I am currently away from the office, returning on August 12th.  As such I will
not be following up on this thread until then.

> 
> Thanks,
> Peng.
> 
> > 
> > > + if (ret) {
> > > + dev_err(dev, "register restart handler
> > failure\n");
> > > + goto err_put_clk;
> > > + }
> > > + }
> > > +
> > >   ret = rproc_add(rproc);
> > >   if (ret) {
> > >   dev_err(dev, "rproc_add failed\n");
> > >
> > > --
> > > 2.37.1
> > >
> > >

Re: [PATCH v2 2/2] remoteproc: imx_rproc: handle system off for i.MX7ULP

[Mathieu Poirier]

On Fri, Jul 19, 2024 at 04:49:04PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan 
> 
> The i.MX7ULP Cortex-A7 is under control of Cortex-M4. The i.MX7ULP Linux
> poweroff and restart rely on rpmsg driver to send a message to Cortex-M4
> firmware. Then Cortex-A7 could poweroff or restart by Cortex-M4 to
> configure the i.MX7ULP power controller properly.
> 
> However the reboot and restart kernel common code use atomic notifier,
> so with blocking tx mailbox will trigger kernel dump, because of
> blocking mailbox will use wait_for_completion_timeout. In such case,
> linux no need to wait for completion.
> 
> Current patch is to use non-blocking tx mailbox channel when system
> is going to poweroff or restart.
> 
> Signed-off-by: Peng Fan 
> ---
>  drivers/remoteproc/imx_rproc.c | 36 
>  1 file changed, 36 insertions(+)
> 
> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index 01cf1dfb2e87..e1abf110abc9 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -114,6 +115,7 @@ struct imx_rproc {
>   u32 entry;  /* cpu start address */
>   u32 core_index;
>   struct dev_pm_domain_list   *pd_list;
> + struct sys_off_data data;

What is this for?  I don't see it used in this patch.

>  };
>  
>  static const struct imx_rproc_att imx_rproc_att_imx93[] = {
> @@ -1050,6 +1052,22 @@ static int imx_rproc_clk_enable(struct imx_rproc *priv)
>   return 0;
>  }
>  
> +static int imx_rproc_sys_off_handler(struct sys_off_data *data)
> +{
> + struct rproc *rproc = data->cb_data;
> + int ret;
> +
> + imx_rproc_free_mbox(rproc);
> +
> + ret = imx_rproc_xtr_mbox_init(rproc, false);
> + if (ret) {
> + dev_err(&rproc->dev, "Failed to request non-blocking mbox\n");
> + return NOTIFY_BAD;
> + }
> +
> + return NOTIFY_DONE;
> +}
> +
>  static int imx_rproc_probe(struct platform_device *pdev)
>  {
>   struct device *dev = &pdev->dev;
> @@ -1104,6 +1122,24 @@ static int imx_rproc_probe(struct platform_device 
> *pdev)
>   if (rproc->state != RPROC_DETACHED)
>   rproc->auto_boot = of_property_read_bool(np, "fsl,auto-boot");
>  
> + if (of_device_is_compatible(dev->of_node, "fsl,imx7ulp-cm4")) {
> + ret = devm_register_sys_off_handler(dev, 
> SYS_OFF_MODE_POWER_OFF_PREPARE,
> + SYS_OFF_PRIO_DEFAULT,
> + imx_rproc_sys_off_handler, 
> rproc);

Why does the mailbox needs to be set up again when the system is going down...

> + if (ret) {
> + dev_err(dev, "register power off handler failure\n");
> + goto err_put_clk;
> + }
> +
> + ret = devm_register_sys_off_handler(dev, 
> SYS_OFF_MODE_RESTART_PREPARE,
> + SYS_OFF_PRIO_DEFAULT,
> + imx_rproc_sys_off_handler, 
> rproc);

... and why does it need to be free'd when the system is going up?

> + if (ret) {
> + dev_err(dev, "register restart handler failure\n");
> + goto err_put_clk;
> + }
> + }
> +
>   ret = rproc_add(rproc);
>   if (ret) {
>   dev_err(dev, "rproc_add failed\n");
> 
> -- 
> 2.37.1
> 
> 

Re: [PATCH v2 0/4] remoteproc: imx_rproc: various patches for misc

[Mathieu Poirier]

On Fri, Jul 19, 2024 at 04:36:10PM +0800, Peng Fan (OSS) wrote:
> This patchset is to upstream a few patches that in NXP downstream for
> quite sometime. For patches directly cherry-picked from NXP downstream,
> I keep the R-b tags.
> 
> Patch 1 is a minor fix to DDR alias.
> Patch 2 was sent out before,
> https://patchwork.kernel.org/project/linux-remoteproc/patch/2022011103.403448-1-peng@oss.nxp.com/#25144792
> this is just a resend
> Patch 3 is to avoid mu interrupt trigger earlier.
> Patch 4 is merge small area to support elf that has large section
> 
> Signed-off-by: Peng Fan 
> ---
> Changes in v2:
> - Add R-b for patch 1,2,4
> - Add Fixes tag for patch 3
> - Drop downstream R-b tag
> - Drop patch 5,6 which will be in a new patchset for 7ULP
> - Link to v1: 
> https://lore.kernel.org/r/20240712-imx_rproc-v1-0-7bcf6732d...@nxp.com
> 
> ---
> Peng Fan (4):
>   remoteproc: imx_rproc: correct ddr alias for i.MX8M
>   remoteproc: imx_rproc: use imx specific hook for find_loaded_rsc_table
>   remoteproc: imx_rproc: initialize workqueue earlier
>   remoteproc: imx_rproc: merge TCML/U
> 

I have applied this set.

Thanks,
Mathieu

>  drivers/remoteproc/imx_rproc.c | 37 +
>  1 file changed, 21 insertions(+), 16 deletions(-)
> ---
> base-commit: f477dd6eede3ecedc8963478571d99ec3bf3f762
> change-id: 20240712-imx_rproc-25f3ab753c58
> 
> Best regards,
> -- 
> Peng Fan 
> 

Re: [PATCH v2] remoteproc: xlnx: add sram support

[Mathieu Poirier]

On Wed, 24 Jul 2024 at 16:04, Tanmay Shah  wrote:
>
> Hello Mathieu,
>
> Thanks for reviews.
>
> All the comments looks good, I will send next revision addressing them all.
>
> On 7/22/24 11:39 AM, Mathieu Poirier wrote:
> > Good morning,
> >
> > On Mon, Jul 15, 2024 at 06:39:54PM -0700, Tanmay Shah wrote:
> >> AMD-Xilinx zynqmp platform contains on-chip sram memory (OCM).
> >> R5 cores can access OCM and access is faster than DDR memory but slower
> >> than TCM memories available. Sram region can have optional multiple
> >> power-domains. Platform management firmware is responsible
> >> to operate these power-domains.
> >>
> >> Signed-off-by: Tanmay Shah 
> >> ---
> >>
> >> Changes in v2:
> >>   - Expand commit message with power-domains related information.
> >>
> >>  drivers/remoteproc/xlnx_r5_remoteproc.c | 131 
> >>  1 file changed, 131 insertions(+)
> >>
> >> diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c 
> >> b/drivers/remoteproc/xlnx_r5_remoteproc.c
> >> index 596f3ffb8935..52ddd42b09e0 100644
> >> --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
> >> +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
> >> @@ -56,6 +56,17 @@ struct mem_bank_data {
> >>  char *bank_name;
> >>  };
> >>
> >> +/**
> >> + * struct zynqmp_sram_bank - sram bank description
> >> + *
> >> + * @sram_res: sram address region information
> >> + * @da: device address of sram
> >> + */
> >> +struct zynqmp_sram_bank {
> >> +struct resource sram_res;
> >> +u32 da;
> >> +};
> >> +
> >>  /**
> >>   * struct mbox_info
> >>   *
> >> @@ -120,6 +131,8 @@ static const struct mem_bank_data 
> >> zynqmp_tcm_banks_lockstep[] = {
> >>   * struct zynqmp_r5_core
> >>   *
> >>   * @rsc_tbl_va: resource table virtual address
> >> + * @sram: Array of sram memories assigned to this core
> >> + * @num_sram: number of sram for this core
> >>   * @dev: device of RPU instance
> >>   * @np: device node of RPU instance
> >>   * @tcm_bank_count: number TCM banks accessible to this RPU
> >> @@ -131,6 +144,8 @@ static const struct mem_bank_data 
> >> zynqmp_tcm_banks_lockstep[] = {
> >>   */
> >>  struct zynqmp_r5_core {
> >>  void __iomem *rsc_tbl_va;
> >> +struct zynqmp_sram_bank **sram;
> >
> > I suggest making @sram an array rather than an array of pointers - it would
> > simplify function zynqmp_r5_get_sram_banks().
> >
>
> Ack.
>
> >> +int num_sram;
> >>  struct device *dev;
> >>  struct device_node *np;
> >>  int tcm_bank_count;
> >> @@ -494,6 +509,40 @@ static int add_mem_regions_carveout(struct rproc 
> >> *rproc)
> >>  return 0;
> >>  }
> >>
> >> +static int add_sram_carveouts(struct rproc *rproc)
> >> +{
> >> +struct zynqmp_r5_core *r5_core = rproc->priv;
> >> +struct rproc_mem_entry *rproc_mem;
> >> +struct zynqmp_sram_bank *sram;
> >> +dma_addr_t dma_addr;
> >> +size_t len;
> >> +int da, i;
> >> +
> >> +for (i = 0; i < r5_core->num_sram; i++) {
> >> +sram = r5_core->sram[i];
> >> +
> >> +dma_addr = (dma_addr_t)sram->sram_res.start;
> >> +len = resource_size(&sram->sram_res);
> >> +da = sram->da;
> >> +
> >> +/* Register associated reserved memory regions */
> >> +rproc_mem = rproc_mem_entry_init(&rproc->dev, NULL,
> >> + (dma_addr_t)dma_addr,
> >> + len, da,
> >> + zynqmp_r5_mem_region_map,
> >> + zynqmp_r5_mem_region_unmap,
> >> + sram->sram_res.name);
> >> +
> >> +rproc_add_carveout(rproc, rproc_mem);
> >> +rproc_coredump_add_segment(rproc, da, len);
> >> +
> >> +dev_dbg(&rproc->dev, "sram carveout %s addr=%llx, da=0x%x, 
> >> size=0x%lx",
> >> +sram->sram_res.name, dma_addr, da, len);
> >> +}
> >> +
> >> +return 0;
> >

Re: [PATCH v2] remoteproc: xlnx: add sram support

[Mathieu Poirier]

Good morning,

On Mon, Jul 15, 2024 at 06:39:54PM -0700, Tanmay Shah wrote:
> AMD-Xilinx zynqmp platform contains on-chip sram memory (OCM).
> R5 cores can access OCM and access is faster than DDR memory but slower
> than TCM memories available. Sram region can have optional multiple
> power-domains. Platform management firmware is responsible
> to operate these power-domains.
> 
> Signed-off-by: Tanmay Shah 
> ---
> 
> Changes in v2:
>   - Expand commit message with power-domains related information.
> 
>  drivers/remoteproc/xlnx_r5_remoteproc.c | 131 
>  1 file changed, 131 insertions(+)
> 
> diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c 
> b/drivers/remoteproc/xlnx_r5_remoteproc.c
> index 596f3ffb8935..52ddd42b09e0 100644
> --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
> +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
> @@ -56,6 +56,17 @@ struct mem_bank_data {
>   char *bank_name;
>  };
>  
> +/**
> + * struct zynqmp_sram_bank - sram bank description
> + *
> + * @sram_res: sram address region information
> + * @da: device address of sram
> + */
> +struct zynqmp_sram_bank {
> + struct resource sram_res;
> + u32 da;
> +};
> +
>  /**
>   * struct mbox_info
>   *
> @@ -120,6 +131,8 @@ static const struct mem_bank_data 
> zynqmp_tcm_banks_lockstep[] = {
>   * struct zynqmp_r5_core
>   *
>   * @rsc_tbl_va: resource table virtual address
> + * @sram: Array of sram memories assigned to this core
> + * @num_sram: number of sram for this core
>   * @dev: device of RPU instance
>   * @np: device node of RPU instance
>   * @tcm_bank_count: number TCM banks accessible to this RPU
> @@ -131,6 +144,8 @@ static const struct mem_bank_data 
> zynqmp_tcm_banks_lockstep[] = {
>   */
>  struct zynqmp_r5_core {
>   void __iomem *rsc_tbl_va;
> + struct zynqmp_sram_bank **sram;

I suggest making @sram an array rather than an array of pointers - it would
simplify function zynqmp_r5_get_sram_banks(). 

> + int num_sram;
>   struct device *dev;
>   struct device_node *np;
>   int tcm_bank_count;
> @@ -494,6 +509,40 @@ static int add_mem_regions_carveout(struct rproc *rproc)
>   return 0;
>  }
>  
> +static int add_sram_carveouts(struct rproc *rproc)
> +{
> + struct zynqmp_r5_core *r5_core = rproc->priv;
> + struct rproc_mem_entry *rproc_mem;
> + struct zynqmp_sram_bank *sram;
> + dma_addr_t dma_addr;
> + size_t len;
> + int da, i;
> +
> + for (i = 0; i < r5_core->num_sram; i++) {
> + sram = r5_core->sram[i];
> +
> + dma_addr = (dma_addr_t)sram->sram_res.start;
> + len = resource_size(&sram->sram_res);
> + da = sram->da;
> +
> + /* Register associated reserved memory regions */
> + rproc_mem = rproc_mem_entry_init(&rproc->dev, NULL,
> +  (dma_addr_t)dma_addr,
> +  len, da,
> +  zynqmp_r5_mem_region_map,
> +  zynqmp_r5_mem_region_unmap,
> +  sram->sram_res.name);
> +
> + rproc_add_carveout(rproc, rproc_mem);
> + rproc_coredump_add_segment(rproc, da, len);
> +
> + dev_dbg(&rproc->dev, "sram carveout %s addr=%llx, da=0x%x, 
> size=0x%lx",
> + sram->sram_res.name, dma_addr, da, len);
> + }
> +
> + return 0;
> +}
> +
>  /*
>   * tcm_mem_unmap()
>   * @rproc: single R5 core's corresponding rproc instance
> @@ -669,6 +718,12 @@ static int zynqmp_r5_rproc_prepare(struct rproc *rproc)
>   return ret;
>   }
>  
> + ret = add_sram_carveouts(rproc);
> + if (ret) {
> + dev_err(&rproc->dev, "failed to get sram carveout %d\n", ret);
> + return ret;
> + }
> +
>   return 0;
>  }
>  
> @@ -881,6 +936,78 @@ static struct zynqmp_r5_core 
> *zynqmp_r5_add_rproc_core(struct device *cdev)
>   return ERR_PTR(ret);
>  }
>  
> +static int zynqmp_r5_get_sram_banks(struct zynqmp_r5_core *r5_core)
> +{
> + struct zynqmp_sram_bank **sram, *sram_data;
> + struct device_node *np = r5_core->np;
> + struct device *dev = r5_core->dev;
> + struct device_node *sram_np;
> + int num_sram, i, ret;
> + u64 abs_addr, size;
> +
> + /* "sram" is optional proprty. Do not fail, if unavailable. */

s/proprty/property

> + if (!of_find_property(r5_core->np, "sram", NULL))
> + return 0;
> +
> + num_sram = of_property_count_elems_of_size(np, "sram", sizeof(phandle));
> + if (num_sram <= 0) {

Any reason this is "<" rather than "<=" ?

> + dev_err(dev, "Invalid sram property, ret = %d\n",
> + num_sram);
> + return -EINVAL;
> + }
> +
> + sram = devm_kcalloc(dev, num_sram,
> + sizeof(struct zynqmp_sram_bank *), GFP_KERNEL);
> + if (!sram)
> +   

Re: [PATCH 1/6] remoteproc: imx_rproc: correct ddr alias for i.MX8M

[Mathieu Poirier]

On Tue, Jul 16, 2024 at 06:49:39PM +0300, Iuliana Prodan wrote:
> Hi Mathieu,
> 
> On 7/16/2024 6:16 PM, Mathieu Poirier wrote:
> > Good morning,
> > 
> > On Fri, Jul 12, 2024 at 04:34:54PM +0800, Peng Fan (OSS) wrote:
> > > From: Peng Fan
> > > 
> > > The DDR Alias address should be 0x4000 according to RM, so correct
> > > it.
> > > 
> > > Fixes: 4ab8f9607aad ("remoteproc: imx_rproc: support i.MX8MQ/M")
> > This commit was merged more than 3 years ago...  I don't see how such a 
> > blatant
> > mistake could have survived this long without causing problems or being 
> > noticed.
> 
> Most probably whoever used imx_rproc and ran into this issue checked NXP
> tree where this is fixed - see here 
> https://github.com/nxp-imx/linux-imx/blob/lf-6.6.y/drivers/remoteproc/imx_rproc.c#L232
> > On top of things checkpatch gives me a warning.
> > 
> > > Reported-by: Terry Lv
> > > Signed-off-by: Peng Fan
> > > ---
> > >   drivers/remoteproc/imx_rproc.c | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/remoteproc/imx_rproc.c 
> > > b/drivers/remoteproc/imx_rproc.c
> > > index 144c8e9a642e..3c8b64db8823 100644
> > > --- a/drivers/remoteproc/imx_rproc.c
> > > +++ b/drivers/remoteproc/imx_rproc.c
> > > @@ -210,7 +210,7 @@ static const struct imx_rproc_att 
> > > imx_rproc_att_imx8mq[] = {
> > >   /* QSPI Code - alias */
> > >   { 0x0800, 0x0800, 0x0800, 0 },
> > >   /* DDR (Code) - alias */
> > > - { 0x1000, 0x8000, 0x0FFE, 0 },
> > > + { 0x1000, 0x4000, 0x0FFE, 0 },
> > Without access to HW or the documentation there is no way for me to assess 
> > the
> > validity of this patch.  Marek, Iuliana and Daniel - please review and test 
> > this
> > patch.
> 
> HW documentation can be downloaded from
> https://www.nxp.com/webapp/Download?colCode=IMX8MDQLQRM (one needs to create
> an account)
> So,
> Reviewed-by: Iuliana Prodan 
>

The very quick reply is much appreciated. I will merge this at the beginning of
the 6.11 cycle.

> Thanks,
> Iulia
> 
> > Thanks,
> > Mathieu
> > 
> > >   /* TCML */
> > >   { 0x1FFE, 0x007E, 0x0002, ATT_OWN  | ATT_IOMEM},
> > >   /* TCMU */
> > > 
> > > -- 
> > > 2.37.1
> > > 

Re: [PATCH 6/6] remoteproc: imx_rproc: handle system off for i.MX7ULP

[Mathieu Poirier]

On Fri, Jul 12, 2024 at 04:34:59PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan 
> 
> The i.MX7ULP Cortex-A7 is under control of Cortex-M4. The i.MX7ULP Linux
> poweroff and restart rely on rpmsg driver to send a message to Cortex-M4
> firmware. Then Cortex-A7 could poweroff or restart by Cortex-M4 to
> configure the i.MX7ULP power controller properly.
> 
> However the reboot and restart kernel common code use atomic notifier,
> so with blocking tx mailbox will trigger kernel dump, because of
> blocking mailbox will use wait_for_completion_timeout. In such case,
> linux no need to wait for completion.
> 
> Current patch is to use non-blocking tx mailbox channel when system
> is going to poweroff or restart.
> 
> Reviewed-by: Jacky Bai 
> Signed-off-by: Peng Fan 
> ---
>  drivers/remoteproc/imx_rproc.c | 36 
>  1 file changed, 36 insertions(+)
> 
> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index 01cf1dfb2e87..e1abf110abc9 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -114,6 +115,7 @@ struct imx_rproc {
>   u32 entry;  /* cpu start address */
>   u32 core_index;
>   struct dev_pm_domain_list   *pd_list;
> + struct sys_off_data data;
>  };
>  
>  static const struct imx_rproc_att imx_rproc_att_imx93[] = {
> @@ -1050,6 +1052,22 @@ static int imx_rproc_clk_enable(struct imx_rproc *priv)
>   return 0;
>  }
>  
> +static int imx_rproc_sys_off_handler(struct sys_off_data *data)
> +{
> + struct rproc *rproc = data->cb_data;
> + int ret;
> +
> + imx_rproc_free_mbox(rproc);
> +
> + ret = imx_rproc_xtr_mbox_init(rproc, false);

This is new functionality and has nothing to do with the rest of this set.
Please introduce patches 5/6 and 6/6 as part of a new patchset.

Thanks,
Mathieu

> + if (ret) {
> + dev_err(&rproc->dev, "Failed to request non-blocking mbox\n");
> + return NOTIFY_BAD;
> + }
> +
> + return NOTIFY_DONE;
> +}
> +
>  static int imx_rproc_probe(struct platform_device *pdev)
>  {
>   struct device *dev = &pdev->dev;
> @@ -1104,6 +1122,24 @@ static int imx_rproc_probe(struct platform_device 
> *pdev)
>   if (rproc->state != RPROC_DETACHED)
>   rproc->auto_boot = of_property_read_bool(np, "fsl,auto-boot");
>  
> + if (of_device_is_compatible(dev->of_node, "fsl,imx7ulp-cm4")) {
> + ret = devm_register_sys_off_handler(dev, 
> SYS_OFF_MODE_POWER_OFF_PREPARE,
> + SYS_OFF_PRIO_DEFAULT,
> + imx_rproc_sys_off_handler, 
> rproc);
> + if (ret) {
> + dev_err(dev, "register power off handler failure\n");
> + goto err_put_clk;
> + }
> +
> + ret = devm_register_sys_off_handler(dev, 
> SYS_OFF_MODE_RESTART_PREPARE,
> + SYS_OFF_PRIO_DEFAULT,
> + imx_rproc_sys_off_handler, 
> rproc);
> + if (ret) {
> + dev_err(dev, "register restart handler failure\n");
> + goto err_put_clk;
> + }
> + }
> +
>   ret = rproc_add(rproc);
>   if (ret) {
>   dev_err(dev, "rproc_add failed\n");
> 
> -- 
> 2.37.1
> 

Re: [PATCH 5/6] remoteproc: imx_rproc: allow tx_block to be set

[Mathieu Poirier]

On Fri, Jul 12, 2024 at 04:34:58PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan 
> 
> Current tx_block is set to true, but there is case that no need to wait
> response. Linux just needs to send data to remote processor, so let's
> allow tx_block could be set to false.

Ok, maybe - but this patch doesn't use the new functionality, i.e nothing
changes.  

> 
> Reviewed-by: Jacky Bai 
> Signed-off-by: Peng Fan 
> ---
>  drivers/remoteproc/imx_rproc.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index 552fccebf7e2..01cf1dfb2e87 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -90,7 +90,7 @@ struct imx_rproc_mem {
>  #define ATT_CORE_MASK   0x
>  #define ATT_CORE(I) BIT((I))
>  
> -static int imx_rproc_xtr_mbox_init(struct rproc *rproc);
> +static int imx_rproc_xtr_mbox_init(struct rproc *rproc, bool tx_block);
>  static void imx_rproc_free_mbox(struct rproc *rproc);
>  
>  struct imx_rproc {
> @@ -369,7 +369,7 @@ static int imx_rproc_start(struct rproc *rproc)
>   struct arm_smccc_res res;
>   int ret;
>  
> - ret = imx_rproc_xtr_mbox_init(rproc);
> + ret = imx_rproc_xtr_mbox_init(rproc, true);
>   if (ret)
>   return ret;
>  
> @@ -629,7 +629,7 @@ static void imx_rproc_kick(struct rproc *rproc, int vqid)
>  
>  static int imx_rproc_attach(struct rproc *rproc)
>  {
> - return imx_rproc_xtr_mbox_init(rproc);
> + return imx_rproc_xtr_mbox_init(rproc, true);
>  }
>  
>  static int imx_rproc_detach(struct rproc *rproc)
> @@ -794,7 +794,7 @@ static void imx_rproc_rx_callback(struct mbox_client *cl, 
> void *msg)
>   queue_work(priv->workqueue, &priv->rproc_work);
>  }
>  
> -static int imx_rproc_xtr_mbox_init(struct rproc *rproc)
> +static int imx_rproc_xtr_mbox_init(struct rproc *rproc, bool tx_block)
>  {
>   struct imx_rproc *priv = rproc->priv;
>   struct device *dev = priv->dev;
> @@ -817,7 +817,7 @@ static int imx_rproc_xtr_mbox_init(struct rproc *rproc)
>  
>   cl = &priv->cl;
>   cl->dev = dev;
> - cl->tx_block = true;
> + cl->tx_block = tx_block;
>   cl->tx_tout = 100;
>   cl->knows_txdone = false;
>   cl->rx_callback = imx_rproc_rx_callback;
> @@ -1083,7 +1083,7 @@ static int imx_rproc_probe(struct platform_device *pdev)
>  
>   INIT_WORK(&priv->rproc_work, imx_rproc_vq_work);
>  
> - ret = imx_rproc_xtr_mbox_init(rproc);
> + ret = imx_rproc_xtr_mbox_init(rproc, true);
>   if (ret)
>   goto err_put_wkq;
>  
> 
> -- 
> 2.37.1
> 

Re: [PATCH 4/6] remoteproc: imx_rproc: merge TCML/U

[Mathieu Poirier]

On Fri, Jul 12, 2024 at 04:34:57PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan 
> 
> Merge contiguous TCML/U regions into one to avoid load elf files which
> has large sections failure.
> 
> Signed-off-by: Peng Fan 
> ---
>  drivers/remoteproc/imx_rproc.c | 18 ++
>  1 file changed, 6 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index 9e99bb27c033..552fccebf7e2 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -119,20 +119,16 @@ struct imx_rproc {
>  static const struct imx_rproc_att imx_rproc_att_imx93[] = {
>   /* dev addr , sys addr  , size  , flags */
>   /* TCM CODE NON-SECURE */
> - { 0x0FFC, 0x201C, 0x0002, ATT_OWN | ATT_IOMEM },
> - { 0x0FFE, 0x201E, 0x0002, ATT_OWN | ATT_IOMEM },
> + { 0x0FFC, 0x201C, 0x0004, ATT_OWN | ATT_IOMEM },
>  
>   /* TCM CODE SECURE */
> - { 0x1FFC, 0x201C, 0x0002, ATT_OWN | ATT_IOMEM },
> - { 0x1FFE, 0x201E, 0x0002, ATT_OWN | ATT_IOMEM },
> + { 0x1FFC, 0x201C, 0x0004, ATT_OWN | ATT_IOMEM },
>  
>   /* TCM SYS NON-SECURE*/
> - { 0x2000, 0x2020, 0x0002, ATT_OWN | ATT_IOMEM },
> - { 0x2002, 0x2022, 0x0002, ATT_OWN | ATT_IOMEM },
> + { 0x2000, 0x2020, 0x0004, ATT_OWN | ATT_IOMEM },
>  
>   /* TCM SYS SECURE*/
> - { 0x3000, 0x2020, 0x0002, ATT_OWN | ATT_IOMEM },
> - { 0x3002, 0x2022, 0x0002, ATT_OWN | ATT_IOMEM },
> + { 0x3000, 0x2020, 0x0004, ATT_OWN | ATT_IOMEM },
>  
>   /* DDR */
>   { 0x8000, 0x8000, 0x1000, 0 },
> @@ -211,10 +207,8 @@ static const struct imx_rproc_att imx_rproc_att_imx8mq[] 
> = {
>   { 0x0800, 0x0800, 0x0800, 0 },
>   /* DDR (Code) - alias */
>   { 0x1000, 0x4000, 0x0FFE, 0 },
> - /* TCML */
> - { 0x1FFE, 0x007E, 0x0002, ATT_OWN  | ATT_IOMEM},
> - /* TCMU */
> - { 0x2000, 0x0080, 0x0002, ATT_OWN  | ATT_IOMEM},
> + /* TCML/U */
> + { 0x1FFE, 0x007E, 0x0004, ATT_OWN  | ATT_IOMEM},

Here too I will need an RB tag by Marek, Iuliana or Daniel.

>   /* OCRAM_S */
>   { 0x2018, 0x0018, 0x8000, ATT_OWN },
>   /* OCRAM */
> 
> -- 
> 2.37.1
> 

Re: [PATCH 3/6] remoteproc: imx_rproc: initialize workqueue earlier

[Mathieu Poirier]

On Fri, Jul 12, 2024 at 04:34:56PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan 
> 
> Initialize workqueue before requesting mailbox channel, otherwise if
> mailbox interrupt comes before workqueue ready, the imx_rproc_rx_callback
> will trigger issue.
> 
> Reviewed-by: Richard Zhu 

All reviews should be done publicly - please remove here and for all the other
patches.

> Signed-off-by: Peng Fan 
> ---
>  drivers/remoteproc/imx_rproc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index 48c48b53a3aa..9e99bb27c033 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -1087,6 +1087,8 @@ static int imx_rproc_probe(struct platform_device *pdev)
>   return -ENOMEM;
>   }
>  
> + INIT_WORK(&priv->rproc_work, imx_rproc_vq_work);
> +

There should be a "Fixes:" tag on this patch.

>   ret = imx_rproc_xtr_mbox_init(rproc);
>   if (ret)
>   goto err_put_wkq;
> @@ -1105,8 +1107,6 @@ static int imx_rproc_probe(struct platform_device *pdev)
>   if (ret)
>   goto err_put_scu;
>  
> - INIT_WORK(&priv->rproc_work, imx_rproc_vq_work);
> -
>   if (rproc->state != RPROC_DETACHED)
>   rproc->auto_boot = of_property_read_bool(np, "fsl,auto-boot");
>  
> 
> -- 
> 2.37.1
> 

Re: [PATCH 1/6] remoteproc: imx_rproc: correct ddr alias for i.MX8M

[Mathieu Poirier]

Good morning,

On Fri, Jul 12, 2024 at 04:34:54PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan 
> 
> The DDR Alias address should be 0x4000 according to RM, so correct
> it.
> 
> Fixes: 4ab8f9607aad ("remoteproc: imx_rproc: support i.MX8MQ/M")

This commit was merged more than 3 years ago...  I don't see how such a blatant
mistake could have survived this long without causing problems or being noticed.
On top of things checkpatch gives me a warning.

> Reported-by: Terry Lv 
> Signed-off-by: Peng Fan 
> ---
>  drivers/remoteproc/imx_rproc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index 144c8e9a642e..3c8b64db8823 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -210,7 +210,7 @@ static const struct imx_rproc_att imx_rproc_att_imx8mq[] 
> = {
>   /* QSPI Code - alias */
>   { 0x0800, 0x0800, 0x0800, 0 },
>   /* DDR (Code) - alias */
> - { 0x1000, 0x8000, 0x0FFE, 0 },
> + { 0x1000, 0x4000, 0x0FFE, 0 },

Without access to HW or the documentation there is no way for me to assess the
validity of this patch.  Marek, Iuliana and Daniel - please review and test this
patch.

Thanks,
Mathieu

>   /* TCML */
>   { 0x1FFE, 0x007E, 0x0002, ATT_OWN  | ATT_IOMEM},
>   /* TCMU */
> 
> -- 
> 2.37.1
> 

Re: [PATCH RFC 1/1] remoteproc: mediatek: Support reserved CMA regions

[Mathieu Poirier]

On Wed, 10 Jul 2024 at 02:42, Shun-yi Wang  wrote:
>
> From: "shun-yi.wang" 
>
> In order to reserve specific Contiguous Memory Allocator (CMA) regions
> for hardware use. When the name of the reserved region contains "cma",
> then a corresponding CMA heap is added.
>
> Signed-off-by: shun-yi.wang 
> ---
>  drivers/remoteproc/mtk_scp.c | 38 
>  1 file changed, 30 insertions(+), 8 deletions(-)
>

I'm not sure what to do with this patch...  Is it a superset of your
other patch [1]?  And if so why is it labelled as an RFC?

Please read the documentation on submitting patches [2] and subscribe
to the remoteproc mailing list to give you an idea of the patch
workflow that is expected.

Thanks,
Mathieu

[1]. [PATCH 1/1] remoteproc: mediatek: Support multiple reserved memory regions
[2]. 
https://elixir.bootlin.com/linux/latest/source/Documentation/process/submitting-patches.rst

> diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
> index e744c07507ee..ca0a4a52ece9 100644
> --- a/drivers/remoteproc/mtk_scp.c
> +++ b/drivers/remoteproc/mtk_scp.c
> @@ -4,6 +4,7 @@
>
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1006,22 +1007,43 @@ EXPORT_SYMBOL_GPL(scp_mapping_dm_addr);
>
>  static int scp_map_memory_region(struct mtk_scp *scp)
>  {
> -   int ret;
> +   int ret, i, err;
> const struct mtk_scp_sizes_data *scp_sizes;
> +   struct device_node *node = scp->dev->of_node;
> +   struct of_phandle_iterator it;
> +
> +   i = 0;
> +   of_for_each_phandle(&it, err, node, "memory-region", NULL, 0) {
> +   ret = of_reserved_mem_device_init_by_idx(scp->dev, node, i);
> +
> +   if (ret) {
> +   dev_err(scp->dev, "failed to assign memory-region: 
> %s\n",
> +   it.node->name);
> +   of_node_put(it.node);
> +   return -ENOMEM;
> +   }
> +
> +#ifdef CONFIG_DMABUF_HEAPS_CMA
> +   if (strstr(it.node->name, "cma")) {
> +   /* Reserved cma memory region */
> +   ret = dma_heap_add_cma(scp->dev);
> +   if (ret) {
> +   dev_err(scp->dev, "Failed to add reserved 
> cma");
> +   of_node_put(it.node);
> +   return ret;
> +   }
> +   }
> +#endif /* CONFIG_DMABUF_HEAPS_CMA */
>
> -   ret = of_reserved_mem_device_init(scp->dev);
> +   i++;
> +   }
>
> /* reserved memory is optional. */
> -   if (ret == -ENODEV) {
> +   if (!i) {
> dev_info(scp->dev, "skipping reserved memory 
> initialization.");
> return 0;
> }
>
> -   if (ret) {
> -   dev_err(scp->dev, "failed to assign memory-region: %d\n", 
> ret);
> -   return -ENOMEM;
> -   }
> -
> /* Reserved SCP code size */
> scp_sizes = scp->data->scp_sizes;
> scp->cpu_addr = dma_alloc_coherent(scp->dev, scp_sizes->max_dram_size,
> --
> 2.18.0
>

Re: [PATCH 1/1] remoteproc: mediatek: Support multiple reserved memory regions

[Mathieu Poirier]

On Wed, Jul 03, 2024 at 07:53:08PM +0800, Shun-yi Wang wrote:
> From: "shun-yi.wang" 
> 
> SCP supports multiple reserved memory regions, intended for
> specific hardwards.
>
> Signed-off-by: shun-yi.wang 
> ---
>  drivers/remoteproc/mtk_scp.c | 25 +
>  1 file changed, 17 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
> index 9ecd5ea04b5f3..1902826cea0af 100644
> --- a/drivers/remoteproc/mtk_scp.c
> +++ b/drivers/remoteproc/mtk_scp.c
> @@ -1006,22 +1006,31 @@ EXPORT_SYMBOL_GPL(scp_mapping_dm_addr);
>  
>  static int scp_map_memory_region(struct mtk_scp *scp)
>  {
> - int ret;
> + int ret, i, err;
>   const struct mtk_scp_sizes_data *scp_sizes;
> + struct device_node *node = scp->dev->of_node;
> + struct of_phandle_iterator it;
> +
> + i = 0;
> + of_for_each_phandle(&it, err, node, "memory-region", NULL, 0) {
> + ret = of_reserved_mem_device_init_by_idx(scp->dev, node, i);
> +
> + if (ret) {
> + dev_err(scp->dev, "failed to assign memory-region: 
> %s\n",
> + it.node->name);
> + of_node_put(it.node);
> + return -ENOMEM;
> + }

With this patch the code is out of sync with the bindings which are still
specifying a maxItems of 1 - please address.

Thanks,
Mathieu

>  
> - ret = of_reserved_mem_device_init(scp->dev);
> + i++;
> + }
>  
>   /* reserved memory is optional. */
> - if (ret == -ENODEV) {
> + if (!i) {
>   dev_info(scp->dev, "skipping reserved memory initialization.");
>   return 0;
>   }
>  
> - if (ret) {
> - dev_err(scp->dev, "failed to assign memory-region: %d\n", ret);
> - return -ENOMEM;
> - }
> -
>   /* Reserved SCP code size */
>   scp_sizes = scp->data->scp_sizes;
>   scp->cpu_addr = dma_alloc_coherent(scp->dev, scp_sizes->max_dram_size,
> -- 
> 2.18.0
> 

Re: [PATCH 0/1] Support multiple reserved memory regions

[Mathieu Poirier]

Good morning,

On Wed, Jul 03, 2024 at 07:53:07PM +0800, Shun-yi Wang wrote:
> From: "shun-yi.wang" 
> 
> Besides the reserved memory region for SCP, there are additional 
> reserved memory regions for specific hardware use.
> Currently, only a single memory region is supported.
> Modifications are made to support multiple memory regions.
> 

This is the changelog that should be in the patch.  Usually there is no need for
a cover letter when there is a single patch in the set.

> shun-yi.wang (1):
>   remoteproc: mediatek: support multiple reserved memory
> 
>  drivers/remoteproc/mtk_scp.c | 25 +
>  1 file changed, 17 insertions(+), 8 deletions(-)
> 
> -- 
> 2.18.0
> 

Re: [PATCH v2 2/2] virtio: fix vq # for balloon

[Mathieu Poirier]

On Wed, 10 Jul 2024 at 05:43, Michael S. Tsirkin  wrote:
>
> virtio balloon communicates to the core that in some
> configurations vq #s are non-contiguous by setting name
> pointer to NULL.
>
> Unfortunately, core then turned around and just made them
> contiguous again. Result is that driver is out of spec.
>
> Implement what the API was supposed to do
> in the 1st place. Compatibility with buggy hypervisors
> is handled inside virtio-balloon, which is the only driver
> making use of this facility, so far.
>
> Message-ID: 
> Fixes: b0c504f15471 ("virtio-balloon: add support for providing free page 
> reports to host")
> Cc: "Alexander Duyck" 
> Signed-off-by: Michael S. Tsirkin 
> ---
>  arch/um/drivers/virtio_uml.c   |  4 ++--
>  drivers/remoteproc/remoteproc_virtio.c |  4 ++--

Reviewed-by: Mathieu Poirier 

>  drivers/s390/virtio/virtio_ccw.c   |  4 ++--
>  drivers/virtio/virtio_mmio.c   |  4 ++--
>  drivers/virtio/virtio_pci_common.c | 11 ---
>  drivers/virtio/virtio_vdpa.c   |  4 ++--
>  6 files changed, 18 insertions(+), 13 deletions(-)
>
> diff --git a/arch/um/drivers/virtio_uml.c b/arch/um/drivers/virtio_uml.c
> index 2b6e701776b6..c903e4959f51 100644
> --- a/arch/um/drivers/virtio_uml.c
> +++ b/arch/um/drivers/virtio_uml.c
> @@ -1019,7 +1019,7 @@ static int vu_find_vqs(struct virtio_device *vdev, 
> unsigned nvqs,
>struct irq_affinity *desc)
>  {
> struct virtio_uml_device *vu_dev = to_virtio_uml_device(vdev);
> -   int i, queue_idx = 0, rc;
> +   int i, rc;
> struct virtqueue *vq;
>
> /* not supported for now */
> @@ -1038,7 +1038,7 @@ static int vu_find_vqs(struct virtio_device *vdev, 
> unsigned nvqs,
> continue;
> }
>
> -   vqs[i] = vu_setup_vq(vdev, queue_idx++, vqi->callback,
> +   vqs[i] = vu_setup_vq(vdev, i, vqi->callback,
>  vqi->name, vqi->ctx);
> if (IS_ERR(vqs[i])) {
> rc = PTR_ERR(vqs[i]);
> diff --git a/drivers/remoteproc/remoteproc_virtio.c 
> b/drivers/remoteproc/remoteproc_virtio.c
> index d3f39009b28e..1019b2825c26 100644
> --- a/drivers/remoteproc/remoteproc_virtio.c
> +++ b/drivers/remoteproc/remoteproc_virtio.c
> @@ -185,7 +185,7 @@ static int rproc_virtio_find_vqs(struct virtio_device 
> *vdev, unsigned int nvqs,
>  struct virtqueue_info vqs_info[],
>  struct irq_affinity *desc)
>  {
> -   int i, ret, queue_idx = 0;
> +   int i, ret;
>
> for (i = 0; i < nvqs; ++i) {
> struct virtqueue_info *vqi = &vqs_info[i];
> @@ -195,7 +195,7 @@ static int rproc_virtio_find_vqs(struct virtio_device 
> *vdev, unsigned int nvqs,
> continue;
> }
>
> -   vqs[i] = rp_find_vq(vdev, queue_idx++, vqi->callback,
> +   vqs[i] = rp_find_vq(vdev, i, vqi->callback,
> vqi->name, vqi->ctx);
> if (IS_ERR(vqs[i])) {
> ret = PTR_ERR(vqs[i]);
> diff --git a/drivers/s390/virtio/virtio_ccw.c 
> b/drivers/s390/virtio/virtio_ccw.c
> index 62eca9419ad7..82a3440bbabb 100644
> --- a/drivers/s390/virtio/virtio_ccw.c
> +++ b/drivers/s390/virtio/virtio_ccw.c
> @@ -694,7 +694,7 @@ static int virtio_ccw_find_vqs(struct virtio_device 
> *vdev, unsigned nvqs,
>  {
> struct virtio_ccw_device *vcdev = to_vc_device(vdev);
> dma64_t *indicatorp = NULL;
> -   int ret, i, queue_idx = 0;
> +   int ret, i;
> struct ccw1 *ccw;
> dma32_t indicatorp_dma = 0;
>
> @@ -710,7 +710,7 @@ static int virtio_ccw_find_vqs(struct virtio_device 
> *vdev, unsigned nvqs,
> continue;
> }
>
> -   vqs[i] = virtio_ccw_setup_vq(vdev, queue_idx++, vqi->callback,
> +   vqs[i] = virtio_ccw_setup_vq(vdev, i, vqi->callback,
>  vqi->name, vqi->ctx, ccw);
> if (IS_ERR(vqs[i])) {
> ret = PTR_ERR(vqs[i]);
> diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c
> index 90e784e7b721..db6a0366f082 100644
> --- a/drivers/virtio/virtio_mmio.c
> +++ b/drivers/virtio/virtio_mmio.c
> @@ -494,7 +494,7 @@ static int vm_find_vqs(struct virtio_device *vdev, 
> unsigned int nvqs,
>  {
> struct virtio_mmio_device *vm_dev = to_virtio_mmio_device(vdev);
> int irq = platform_get_irq(vm_dev->pdev,

Re: [PATCH] remoteproc: mediatek: Increase MT8188/MT8195 SCP core0 DRAM size

[Mathieu Poirier]

On Wed, Jul 03, 2024 at 11:05:59AM +0200, AngeloGioacchino Del Regno wrote:
> Il 03/07/24 05:44, Jason Chen ha scritto:
> > The current DRAM size is insufficient for the HEVC feature, which
> > requires more memory for proper functionality. This change ensures the
> > feature has the necessary resources.
> > 
> > Signed-off-by: Jason Chen 
> 
> Reviewed-by: AngeloGioacchino Del Regno 
> 
>

I have applied this patch.

Thanks,
Mathieu

> 

Re: [PATCH v8 2/5] remoteproc: Add TEE support

[Mathieu Poirier]

On Fri, Jul 05, 2024 at 09:33:55AM +0200, Arnaud POULIQUEN wrote:
> 
> 
> On 7/4/24 17:32, Mathieu Poirier wrote:
> > On Thu, Jul 04, 2024 at 10:05:24AM +0200, Arnaud POULIQUEN wrote:
> >>
> >>
> >> On 7/3/24 17:14, Mathieu Poirier wrote:
> >>> On Wed, Jul 03, 2024 at 09:19:44AM +0200, Arnaud POULIQUEN wrote:
> >>>> Hello Mathieu
> >>>>
> >>>> On 7/2/24 18:44, Mathieu Poirier wrote:
> >>>>> Good morning,
> >>>>>
> >>>>> On Fri, Jun 21, 2024 at 04:37:56PM +0200, Arnaud Pouliquen wrote:
> >>>>>> Add a remoteproc TEE (Trusted Execution Environment) driver
> >>>>>> that will be probed by the TEE bus. If the associated Trusted
> >>>>>> application is supported on secure part this driver offers a client
> >>>>>> interface to load a firmware by the secure part.
> >>>>>> This firmware could be authenticated by the secure trusted application.
> >>>>>>
> >>>>>> Signed-off-by: Arnaud Pouliquen 
> >>>>>> ---
> >>>>>> Updates vs previous version:
> >>>>>> - rename tee_remoteproc.* file to rmeoteproc_tee.*,
> >>>>>> - rename TEE_REMOTEPROC config to REMOTEPROC_TEE,
> >>>>>> - remove "stm32" in some variable declarations,
> >>>>>> - remove useless "remoteproc_internal.h" include,
> >>>>>> - fix tee_rproc_ctx devm_kzalloc.
> >>>>>> - rework module description
> >>>>>> ---
> >>>>>>  drivers/remoteproc/Kconfig  |  10 +
> >>>>>>  drivers/remoteproc/Makefile |   1 +
> >>>>>>  drivers/remoteproc/remoteproc_tee.c | 446 
> >>>>>>  include/linux/remoteproc.h  |   4 +
> >>>>>>  include/linux/remoteproc_tee.h  | 100 +++
> >>>>>>  5 files changed, 561 insertions(+)
> >>>>>>  create mode 100644 drivers/remoteproc/remoteproc_tee.c
> >>>>>>  create mode 100644 include/linux/remoteproc_tee.h
> >>>>>>
> >>>>>> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> >>>>>> index 48845dc8fa85..278f197acb90 100644
> >>>>>> --- a/drivers/remoteproc/Kconfig
> >>>>>> +++ b/drivers/remoteproc/Kconfig
> >>>>>> @@ -365,6 +365,16 @@ config XLNX_R5_REMOTEPROC
> >>>>>>  
> >>>>>>  It's safe to say N if not interested in using RPU r5f cores.
> >>>>>>  
> >>>>>> +
> >>>>>> +config REMOTEPROC_TEE
> >>>>>> +  tristate "Remoteproc support by a TEE application"
> >>>>>> +  depends on OPTEE
> >>>>>> +  help
> >>>>>> +Support a remote processor with a TEE application. The Trusted
> >>>>>> +Execution Context is responsible for loading the trusted 
> >>>>>> firmware
> >>>>>> +image and managing the remote processor's lifecycle.
> >>>>>> +This can be either built-in or a loadable module.
> >>>>>> +
> >>>>>>  endif # REMOTEPROC
> >>>>>>  
> >>>>>>  endmenu
> >>>>>> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> >>>>>> index 91314a9b43ce..b4eb37177005 100644
> >>>>>> --- a/drivers/remoteproc/Makefile
> >>>>>> +++ b/drivers/remoteproc/Makefile
> >>>>>> @@ -36,6 +36,7 @@ obj-$(CONFIG_RCAR_REMOTEPROC)+= 
> >>>>>> rcar_rproc.o
> >>>>>>  obj-$(CONFIG_ST_REMOTEPROC)   += st_remoteproc.o
> >>>>>>  obj-$(CONFIG_ST_SLIM_REMOTEPROC)  += st_slim_rproc.o
> >>>>>>  obj-$(CONFIG_STM32_RPROC) += stm32_rproc.o
> >>>>>> +obj-$(CONFIG_REMOTEPROC_TEE)  += remoteproc_tee.o
> >>>>>>  obj-$(CONFIG_TI_K3_DSP_REMOTEPROC)+= ti_k3_dsp_remoteproc.o
> >>>>>>  obj-$(CONFIG_TI_K3_R5_REMOTEPROC) += ti_k3_r5_remoteproc.o
> >>>>>>  obj-$(CONFIG_XLNX_R5_REMOTEPROC)  += xlnx_r5_remoteproc.o
> >>>>>> diff --git a/drivers/remo

Re: [PATCH v6] remoteproc: xlnx: add attach detach support

[Mathieu Poirier]

On Thu, Jun 27, 2024 at 10:29:38AM -0700, Tanmay Shah wrote:
> It is possible that remote processor is already running before
> linux boot or remoteproc platform driver probe. Implement required
> remoteproc framework ops to provide resource table address and
> connect or disconnect with remote processor in such case.
> 
> Signed-off-by: Tanmay Shah 
> ---
> 
> Changes in v6:
>   - Move rproc state check to add_tcm_carveout
>   - free node reference using of_node_put
>   - fix iounmap use
> 
> Changes in v5:
>   - Fix comment on assigning DETACHED state to remoteproc instance
> during driver probe.
>   - Fix patch subject and remove "drivers"
> 
> Changes in v4:
>   - Move change log out of commit text
> 
> Changes in v3:
>   - Drop SRAM patch from the series
>   - Change type from "struct resource_table *" to void __iomem *
>   - Change comment format from /** to /*
>   - Remove unmap of resource table va address during detach, allowing
> attach-detach-reattach use case.
>   - Unmap rsc_data_va after retrieving resource table data structure.
>   - Unmap resource table va during driver remove op
> 
> Changes in v2:
>   - Fix typecast warnings reported using sparse tool.
>   - Fix following sparse warnings:
>
>  drivers/remoteproc/xlnx_r5_remoteproc.c | 151 
>  1 file changed, 151 insertions(+)
>

Applied.

Thanks,
Mathieu

> diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c 
> b/drivers/remoteproc/xlnx_r5_remoteproc.c
> index 84243d1dff9f..596f3ffb8935 100644
> --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
> +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
> @@ -25,6 +25,10 @@
>  /* RX mailbox client buffer max length */
>  #define MBOX_CLIENT_BUF_MAX  (IPI_BUF_LEN_MAX + \
>sizeof(struct zynqmp_ipi_message))
> +
> +#define RSC_TBL_XLNX_MAGIC   ((uint32_t)'x' << 24 | (uint32_t)'a' << 16 | \
> +  (uint32_t)'m' << 8 | (uint32_t)'p')
> +
>  /*
>   * settings for RPU cluster mode which
>   * reflects possible values of xlnx,cluster-mode dt-property
> @@ -73,6 +77,26 @@ struct mbox_info {
>   struct mbox_chan *rx_chan;
>  };
>  
> +/**
> + * struct rsc_tbl_data
> + *
> + * Platform specific data structure used to sync resource table address.
> + * It's important to maintain order and size of each field on remote side.
> + *
> + * @version: version of data structure
> + * @magic_num: 32-bit magic number.
> + * @comp_magic_num: complement of above magic number
> + * @rsc_tbl_size: resource table size
> + * @rsc_tbl: resource table address
> + */
> +struct rsc_tbl_data {
> + const int version;
> + const u32 magic_num;
> + const u32 comp_magic_num;
> + const u32 rsc_tbl_size;
> + const uintptr_t rsc_tbl;
> +} __packed;
> +
>  /*
>   * Hardcoded TCM bank values. This will stay in driver to maintain backward
>   * compatibility with device-tree that does not have TCM information.
> @@ -95,20 +119,24 @@ static const struct mem_bank_data 
> zynqmp_tcm_banks_lockstep[] = {
>  /**
>   * struct zynqmp_r5_core
>   *
> + * @rsc_tbl_va: resource table virtual address
>   * @dev: device of RPU instance
>   * @np: device node of RPU instance
>   * @tcm_bank_count: number TCM banks accessible to this RPU
>   * @tcm_banks: array of each TCM bank data
>   * @rproc: rproc handle
> + * @rsc_tbl_size: resource table size retrieved from remote
>   * @pm_domain_id: RPU CPU power domain id
>   * @ipi: pointer to mailbox information
>   */
>  struct zynqmp_r5_core {
> + void __iomem *rsc_tbl_va;
>   struct device *dev;
>   struct device_node *np;
>   int tcm_bank_count;
>   struct mem_bank_data **tcm_banks;
>   struct rproc *rproc;
> + u32 rsc_tbl_size;
>   u32 pm_domain_id;
>   struct mbox_info *ipi;
>  };
> @@ -557,6 +585,14 @@ static int add_tcm_banks(struct rproc *rproc)
>   dev_dbg(dev, "TCM carveout %s addr=%llx, da=0x%x, size=0x%lx",
>   bank_name, bank_addr, da, bank_size);
>  
> + /*
> +  * In DETACHED state firmware is already running so no need to
> +  * request add TCM registers. However, request TCM PD node to 
> let
> +  * platform management firmware know that TCM is in use.
> +  */
> + if (rproc->state == RPROC_DETACHED)
> + continue;
> +
>   rproc_mem = rproc_mem_entry_init(dev, NULL, bank_addr,
>bank_size, da,
>tcm_mem_map, tcm_mem_unmap,
> @@ -662,6 +698,107 @@ static int zynqmp_r5_rproc_unprepare(struct rproc 
> *rproc)
>   return 0;
>  }
>  
> +static struct resource_table *zynqmp_r5_get_loaded_rsc_table(struct rproc 
> *rproc,
> +  size_t *size)
> +{
> + struct zynqmp_r5_core *r5_core;
> +
> + r5_core = rproc->priv;
> +
> + *size = r5_core->rsc_tbl_size;
> +
> + re

Re: [PATCH v2] remoteproc: k3-dsp: Fix log levels where appropriate

[Mathieu Poirier]

On Wed, Jun 26, 2024 at 12:14:38PM -0700, Garrett Giordano wrote:
> Driver was logging information as errors. Changed dev_err to dev_dbg
> where appropriate.
> 
> Signed-off-by: Garrett Giordano 
> ---
> -v2
>   - Change from dev_info to dev_dbg
>   - Drop k3-r5 PATCH
> ---
>  drivers/remoteproc/ti_k3_dsp_remoteproc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

Applied.

Thanks,
Mathieu

> diff --git a/drivers/remoteproc/ti_k3_dsp_remoteproc.c 
> b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
> index 3555b535b168..a22d41689a7d 100644
> --- a/drivers/remoteproc/ti_k3_dsp_remoteproc.c
> +++ b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
> @@ -327,7 +327,7 @@ static int k3_dsp_rproc_start(struct rproc *rproc)
>   goto put_mbox;
>   }
> 
> - dev_err(dev, "booting DSP core using boot addr = 0x%x\n", boot_addr);
> + dev_dbg(dev, "booting DSP core using boot addr = 0x%x\n", boot_addr);
>   ret = ti_sci_proc_set_config(kproc->tsp, boot_addr, 0, 0);
>   if (ret)
>   goto put_mbox;
> --
> 2.25.1
> 

Re: [PATCH v8 2/5] remoteproc: Add TEE support

[Mathieu Poirier]

On Thu, Jul 04, 2024 at 10:05:24AM +0200, Arnaud POULIQUEN wrote:
> 
> 
> On 7/3/24 17:14, Mathieu Poirier wrote:
> > On Wed, Jul 03, 2024 at 09:19:44AM +0200, Arnaud POULIQUEN wrote:
> >> Hello Mathieu
> >>
> >> On 7/2/24 18:44, Mathieu Poirier wrote:
> >>> Good morning,
> >>>
> >>> On Fri, Jun 21, 2024 at 04:37:56PM +0200, Arnaud Pouliquen wrote:
> >>>> Add a remoteproc TEE (Trusted Execution Environment) driver
> >>>> that will be probed by the TEE bus. If the associated Trusted
> >>>> application is supported on secure part this driver offers a client
> >>>> interface to load a firmware by the secure part.
> >>>> This firmware could be authenticated by the secure trusted application.
> >>>>
> >>>> Signed-off-by: Arnaud Pouliquen 
> >>>> ---
> >>>> Updates vs previous version:
> >>>> - rename tee_remoteproc.* file to rmeoteproc_tee.*,
> >>>> - rename TEE_REMOTEPROC config to REMOTEPROC_TEE,
> >>>> - remove "stm32" in some variable declarations,
> >>>> - remove useless "remoteproc_internal.h" include,
> >>>> - fix tee_rproc_ctx devm_kzalloc.
> >>>> - rework module description
> >>>> ---
> >>>>  drivers/remoteproc/Kconfig  |  10 +
> >>>>  drivers/remoteproc/Makefile |   1 +
> >>>>  drivers/remoteproc/remoteproc_tee.c | 446 
> >>>>  include/linux/remoteproc.h  |   4 +
> >>>>  include/linux/remoteproc_tee.h  | 100 +++
> >>>>  5 files changed, 561 insertions(+)
> >>>>  create mode 100644 drivers/remoteproc/remoteproc_tee.c
> >>>>  create mode 100644 include/linux/remoteproc_tee.h
> >>>>
> >>>> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> >>>> index 48845dc8fa85..278f197acb90 100644
> >>>> --- a/drivers/remoteproc/Kconfig
> >>>> +++ b/drivers/remoteproc/Kconfig
> >>>> @@ -365,6 +365,16 @@ config XLNX_R5_REMOTEPROC
> >>>>  
> >>>>It's safe to say N if not interested in using RPU r5f cores.
> >>>>  
> >>>> +
> >>>> +config REMOTEPROC_TEE
> >>>> +tristate "Remoteproc support by a TEE application"
> >>>> +depends on OPTEE
> >>>> +help
> >>>> +  Support a remote processor with a TEE application. The Trusted
> >>>> +  Execution Context is responsible for loading the trusted 
> >>>> firmware
> >>>> +  image and managing the remote processor's lifecycle.
> >>>> +  This can be either built-in or a loadable module.
> >>>> +
> >>>>  endif # REMOTEPROC
> >>>>  
> >>>>  endmenu
> >>>> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> >>>> index 91314a9b43ce..b4eb37177005 100644
> >>>> --- a/drivers/remoteproc/Makefile
> >>>> +++ b/drivers/remoteproc/Makefile
> >>>> @@ -36,6 +36,7 @@ obj-$(CONFIG_RCAR_REMOTEPROC)  += rcar_rproc.o
> >>>>  obj-$(CONFIG_ST_REMOTEPROC) += st_remoteproc.o
> >>>>  obj-$(CONFIG_ST_SLIM_REMOTEPROC)+= st_slim_rproc.o
> >>>>  obj-$(CONFIG_STM32_RPROC)   += stm32_rproc.o
> >>>> +obj-$(CONFIG_REMOTEPROC_TEE)+= remoteproc_tee.o
> >>>>  obj-$(CONFIG_TI_K3_DSP_REMOTEPROC)  += ti_k3_dsp_remoteproc.o
> >>>>  obj-$(CONFIG_TI_K3_R5_REMOTEPROC)   += ti_k3_r5_remoteproc.o
> >>>>  obj-$(CONFIG_XLNX_R5_REMOTEPROC)+= xlnx_r5_remoteproc.o
> >>>> diff --git a/drivers/remoteproc/remoteproc_tee.c 
> >>>> b/drivers/remoteproc/remoteproc_tee.c
> >>>> new file mode 100644
> >>>> index ..70cb67451767
> >>>> --- /dev/null
> >>>> +++ b/drivers/remoteproc/remoteproc_tee.c
> >>>> @@ -0,0 +1,446 @@
> >>>> +// SPDX-License-Identifier: GPL-2.0-or-later
> >>>> +/*
> >>>> + * Copyright (C) STMicroelectronics 2024
> >>>> + * Author: Arnaud Pouliquen 
> >>>> + */
> >>>> +
> >>>> +#include 
> >>>> +#include 
> >>>> +#include 
> >>>> +#include

Re: [PATCH v8 2/5] remoteproc: Add TEE support

[Mathieu Poirier]

On Fri, Jun 21, 2024 at 04:37:56PM +0200, Arnaud Pouliquen wrote:
> Add a remoteproc TEE (Trusted Execution Environment) driver
> that will be probed by the TEE bus. If the associated Trusted
> application is supported on secure part this driver offers a client
> interface to load a firmware by the secure part.
> This firmware could be authenticated by the secure trusted application.
> 
> Signed-off-by: Arnaud Pouliquen 
> ---
> Updates vs previous version:
> - rename tee_remoteproc.* file to rmeoteproc_tee.*,
> - rename TEE_REMOTEPROC config to REMOTEPROC_TEE,
> - remove "stm32" in some variable declarations,
> - remove useless "remoteproc_internal.h" include,
> - fix tee_rproc_ctx devm_kzalloc.
> - rework module description
> ---
>  drivers/remoteproc/Kconfig  |  10 +
>  drivers/remoteproc/Makefile |   1 +
>  drivers/remoteproc/remoteproc_tee.c | 446 
>  include/linux/remoteproc.h  |   4 +
>  include/linux/remoteproc_tee.h  | 100 +++
>  5 files changed, 561 insertions(+)
>  create mode 100644 drivers/remoteproc/remoteproc_tee.c
>  create mode 100644 include/linux/remoteproc_tee.h
> 
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index 48845dc8fa85..278f197acb90 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -365,6 +365,16 @@ config XLNX_R5_REMOTEPROC
>  
> It's safe to say N if not interested in using RPU r5f cores.
>  
> +
> +config REMOTEPROC_TEE
> + tristate "Remoteproc support by a TEE application"
> + depends on OPTEE
> + help
> +   Support a remote processor with a TEE application. The Trusted
> +   Execution Context is responsible for loading the trusted firmware
> +   image and managing the remote processor's lifecycle.
> +   This can be either built-in or a loadable module.
> +
>  endif # REMOTEPROC
>  
>  endmenu
> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> index 91314a9b43ce..b4eb37177005 100644
> --- a/drivers/remoteproc/Makefile
> +++ b/drivers/remoteproc/Makefile
> @@ -36,6 +36,7 @@ obj-$(CONFIG_RCAR_REMOTEPROC)   += rcar_rproc.o
>  obj-$(CONFIG_ST_REMOTEPROC)  += st_remoteproc.o
>  obj-$(CONFIG_ST_SLIM_REMOTEPROC) += st_slim_rproc.o
>  obj-$(CONFIG_STM32_RPROC)+= stm32_rproc.o
> +obj-$(CONFIG_REMOTEPROC_TEE) += remoteproc_tee.o
>  obj-$(CONFIG_TI_K3_DSP_REMOTEPROC)   += ti_k3_dsp_remoteproc.o
>  obj-$(CONFIG_TI_K3_R5_REMOTEPROC)+= ti_k3_r5_remoteproc.o
>  obj-$(CONFIG_XLNX_R5_REMOTEPROC) += xlnx_r5_remoteproc.o
> diff --git a/drivers/remoteproc/remoteproc_tee.c 
> b/drivers/remoteproc/remoteproc_tee.c
> new file mode 100644
> index ..70cb67451767
> --- /dev/null
> +++ b/drivers/remoteproc/remoteproc_tee.c
> @@ -0,0 +1,446 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) STMicroelectronics 2024
> + * Author: Arnaud Pouliquen 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define MAX_TEE_PARAM_ARRY_MEMBER4
> +
> +/*
> + * Authentication of the firmware and load in the remote processor memory
> + *
> + * [in]  params[0].value.a:  unique 32bit identifier of the remote processor
> + * [in]   params[1].memref:  buffer containing the image of the 
> buffer
> + */
> +#define TA_RPROC_FW_CMD_LOAD_FW  1
> +
> +/*
> + * Start the remote processor
> + *
> + * [in]  params[0].value.a:  unique 32bit identifier of the remote processor
> + */
> +#define TA_RPROC_FW_CMD_START_FW 2
> +
> +/*
> + * Stop the remote processor
> + *
> + * [in]  params[0].value.a:  unique 32bit identifier of the remote processor
> + */
> +#define TA_RPROC_FW_CMD_STOP_FW  3
> +
> +/*
> + * Return the address of the resource table, or 0 if not found
> + * No check is done to verify that the address returned is accessible by
> + * the non secure context. If the resource table is loaded in a protected
> + * memory the access by the non secure context will lead to a data abort.
> + *
> + * [in]  params[0].value.a:  unique 32bit identifier of the remote processor
> + * [out]  params[1].value.a: 32bit LSB resource table memory address
> + * [out]  params[1].value.b: 32bit MSB resource table memory address
> + * [out]  params[2].value.a: 32bit LSB resource table memory size
> + * [out]  params[2].value.b: 32bit MSB resource table memory size
> + */
> +#define TA_RPROC_FW_CMD_GET_RSC_TABLE4
> +
> +/*
> + * Return the address of the core dump
> + *
> + * [in]  params[0].value.a:  unique 32bit identifier of the remote processor
> + * [out] params[1].memref:   address of the core dump image if exist,
> + *   else return Null
> + */
> +#define TA_RPROC_FW_CMD_GET_COREDUMP 5
> +
> +struct tee_rproc_context {
> + struct list_head sessions;
> + struct tee_context *tee_ctx;
> + struct device *dev;
> +};
> +
> +static struct tee

Re: [PATCH v8 2/5] remoteproc: Add TEE support

[Mathieu Poirier]

On Wed, Jul 03, 2024 at 09:19:44AM +0200, Arnaud POULIQUEN wrote:
> Hello Mathieu
> 
> On 7/2/24 18:44, Mathieu Poirier wrote:
> > Good morning,
> > 
> > On Fri, Jun 21, 2024 at 04:37:56PM +0200, Arnaud Pouliquen wrote:
> >> Add a remoteproc TEE (Trusted Execution Environment) driver
> >> that will be probed by the TEE bus. If the associated Trusted
> >> application is supported on secure part this driver offers a client
> >> interface to load a firmware by the secure part.
> >> This firmware could be authenticated by the secure trusted application.
> >>
> >> Signed-off-by: Arnaud Pouliquen 
> >> ---
> >> Updates vs previous version:
> >> - rename tee_remoteproc.* file to rmeoteproc_tee.*,
> >> - rename TEE_REMOTEPROC config to REMOTEPROC_TEE,
> >> - remove "stm32" in some variable declarations,
> >> - remove useless "remoteproc_internal.h" include,
> >> - fix tee_rproc_ctx devm_kzalloc.
> >> - rework module description
> >> ---
> >>  drivers/remoteproc/Kconfig  |  10 +
> >>  drivers/remoteproc/Makefile |   1 +
> >>  drivers/remoteproc/remoteproc_tee.c | 446 
> >>  include/linux/remoteproc.h  |   4 +
> >>  include/linux/remoteproc_tee.h  | 100 +++
> >>  5 files changed, 561 insertions(+)
> >>  create mode 100644 drivers/remoteproc/remoteproc_tee.c
> >>  create mode 100644 include/linux/remoteproc_tee.h
> >>
> >> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> >> index 48845dc8fa85..278f197acb90 100644
> >> --- a/drivers/remoteproc/Kconfig
> >> +++ b/drivers/remoteproc/Kconfig
> >> @@ -365,6 +365,16 @@ config XLNX_R5_REMOTEPROC
> >>  
> >>  It's safe to say N if not interested in using RPU r5f cores.
> >>  
> >> +
> >> +config REMOTEPROC_TEE
> >> +  tristate "Remoteproc support by a TEE application"
> >> +  depends on OPTEE
> >> +  help
> >> +Support a remote processor with a TEE application. The Trusted
> >> +Execution Context is responsible for loading the trusted firmware
> >> +image and managing the remote processor's lifecycle.
> >> +This can be either built-in or a loadable module.
> >> +
> >>  endif # REMOTEPROC
> >>  
> >>  endmenu
> >> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> >> index 91314a9b43ce..b4eb37177005 100644
> >> --- a/drivers/remoteproc/Makefile
> >> +++ b/drivers/remoteproc/Makefile
> >> @@ -36,6 +36,7 @@ obj-$(CONFIG_RCAR_REMOTEPROC)+= rcar_rproc.o
> >>  obj-$(CONFIG_ST_REMOTEPROC)   += st_remoteproc.o
> >>  obj-$(CONFIG_ST_SLIM_REMOTEPROC)  += st_slim_rproc.o
> >>  obj-$(CONFIG_STM32_RPROC) += stm32_rproc.o
> >> +obj-$(CONFIG_REMOTEPROC_TEE)  += remoteproc_tee.o
> >>  obj-$(CONFIG_TI_K3_DSP_REMOTEPROC)+= ti_k3_dsp_remoteproc.o
> >>  obj-$(CONFIG_TI_K3_R5_REMOTEPROC) += ti_k3_r5_remoteproc.o
> >>  obj-$(CONFIG_XLNX_R5_REMOTEPROC)  += xlnx_r5_remoteproc.o
> >> diff --git a/drivers/remoteproc/remoteproc_tee.c 
> >> b/drivers/remoteproc/remoteproc_tee.c
> >> new file mode 100644
> >> index ..70cb67451767
> >> --- /dev/null
> >> +++ b/drivers/remoteproc/remoteproc_tee.c
> >> @@ -0,0 +1,446 @@
> >> +// SPDX-License-Identifier: GPL-2.0-or-later
> >> +/*
> >> + * Copyright (C) STMicroelectronics 2024
> >> + * Author: Arnaud Pouliquen 
> >> + */
> >> +
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +
> >> +#define MAX_TEE_PARAM_ARRY_MEMBER 4
> >> +
> >> +/*
> >> + * Authentication of the firmware and load in the remote processor memory
> >> + *
> >> + * [in]  params[0].value.a:   unique 32bit identifier of the remote 
> >> processor
> >> + * [in]params[1].memref:  buffer containing the image of the 
> >> buffer
> >> + */
> >> +#define TA_RPROC_FW_CMD_LOAD_FW   1
> >> +
> >> +/*
> >> + * Start the remote processor
> >> + *
> >> + * [in]  params[0].value.a:   unique 32bit identifier of the remote 
> >> processor
> >> + */
> >> +#define TA_RPROC_FW_CMD_START_FW  2
> 

Re: [PATCH v8 5/5] remoteproc: stm32: Add support of an OP-TEE TA to load the firmware

[Mathieu Poirier]

On Fri, Jun 21, 2024 at 04:37:59PM +0200, Arnaud Pouliquen wrote:
> The new TEE remoteproc device is used to manage remote firmware in a

Device or driver?

> secure, trusted context. The 'st,stm32mp1-m4-tee' compatibility is
> introduced to delegate the loading of the firmware to the trusted
> execution context. In such cases, the firmware should be signed and
> adhere to the image format defined by the TEE.
> 
> Signed-off-by: Arnaud Pouliquen 
> ---
>  drivers/remoteproc/stm32_rproc.c | 63 ++--
>  1 file changed, 60 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/remoteproc/stm32_rproc.c 
> b/drivers/remoteproc/stm32_rproc.c
> index 8cd838df4e92..fd905b3cf206 100644
> --- a/drivers/remoteproc/stm32_rproc.c
> +++ b/drivers/remoteproc/stm32_rproc.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -257,6 +258,19 @@ static int stm32_rproc_release(struct rproc *rproc)
>   return 0;
>  }
>  
> +static int stm32_rproc_tee_stop(struct rproc *rproc)
> +{
> + int err;
> +
> + stm32_rproc_request_shutdown(rproc);
> +
> + err = tee_rproc_stop(rproc);
> + if (err)
> + return err;
> +
> + return stm32_rproc_release(rproc);
> +}
> +
>  static int stm32_rproc_prepare(struct rproc *rproc)
>  {
>   struct device *dev = rproc->dev.parent;
> @@ -693,8 +707,20 @@ static const struct rproc_ops st_rproc_ops = {
>   .get_boot_addr  = rproc_elf_get_boot_addr,
>  };
>  
> +static const struct rproc_ops st_rproc_tee_ops = {
> + .prepare= stm32_rproc_prepare,
> + .start  = tee_rproc_start,
> + .stop   = stm32_rproc_tee_stop,
> + .kick   = stm32_rproc_kick,
> + .load   = tee_rproc_load_fw,
> + .parse_fw   = tee_rproc_parse_fw,
> + .find_loaded_rsc_table = tee_rproc_find_loaded_rsc_table,
> +
> +};
> +
>  static const struct of_device_id stm32_rproc_match[] = {
>   { .compatible = "st,stm32mp1-m4" },
> + { .compatible = "st,stm32mp1-m4-tee" },
>   {},
>  };
>  MODULE_DEVICE_TABLE(of, stm32_rproc_match);
> @@ -853,17 +879,42 @@ static int stm32_rproc_probe(struct platform_device 
> *pdev)
>   struct device *dev = &pdev->dev;
>   struct stm32_rproc *ddata;
>   struct device_node *np = dev->of_node;
> + struct tee_rproc *trproc = NULL;
>   struct rproc *rproc;
>   unsigned int state;
> + u32 proc_id;
>   int ret;
>  
>   ret = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(32));
>   if (ret)
>   return ret;
>  
> - rproc = devm_rproc_alloc(dev, np->name, &st_rproc_ops, NULL, 
> sizeof(*ddata));
> - if (!rproc)
> - return -ENOMEM;
> + if (of_device_is_compatible(np, "st,stm32mp1-m4-tee")) {
> + /*
> +  * Delegate the firmware management to the secure context.
> +  * The firmware loaded has to be signed.
> +  */
> + ret = of_property_read_u32(np, "st,proc-id", &proc_id);
> + if (ret) {
> + dev_err(dev, "failed to read st,rproc-id property\n");
> + return ret;
> + }
> +
> + rproc = devm_rproc_alloc(dev, np->name, &st_rproc_tee_ops, 
> NULL, sizeof(*ddata));
> + if (!rproc)
> + return -ENOMEM;
> +
> + trproc = tee_rproc_register(dev, rproc, proc_id);
> + if (IS_ERR(trproc)) {
> + dev_err_probe(dev, PTR_ERR(trproc),
> +   "signed firmware not supported by TEE\n");
> + return PTR_ERR(trproc);
> + }
> + } else {
> + rproc = devm_rproc_alloc(dev, np->name, &st_rproc_ops, NULL, 
> sizeof(*ddata));
> + if (!rproc)
> + return -ENOMEM;
> + }
>  
>   ddata = rproc->priv;
>  
> @@ -915,6 +966,9 @@ static int stm32_rproc_probe(struct platform_device *pdev)
>   dev_pm_clear_wake_irq(dev);
>   device_init_wakeup(dev, false);
>   }
> + if (trproc)
> + tee_rproc_unregister(trproc);
> +
>   return ret;
>  }
>  
> @@ -935,6 +989,9 @@ static void stm32_rproc_remove(struct platform_device 
> *pdev)
>   dev_pm_clear_wake_irq(dev);
>   device_init_wakeup(dev, false);
>   }
> + if (rproc->tee_interface)
> + tee_rproc_unregister(rproc->tee_interface);
> +
>  }
>  
>  static int stm32_rproc_suspend(struct device *dev)
> -- 
> 2.25.1
> 

Re: [PATCH v8 2/5] remoteproc: Add TEE support

[Mathieu Poirier]

Good morning,

On Fri, Jun 21, 2024 at 04:37:56PM +0200, Arnaud Pouliquen wrote:
> Add a remoteproc TEE (Trusted Execution Environment) driver
> that will be probed by the TEE bus. If the associated Trusted
> application is supported on secure part this driver offers a client
> interface to load a firmware by the secure part.
> This firmware could be authenticated by the secure trusted application.
> 
> Signed-off-by: Arnaud Pouliquen 
> ---
> Updates vs previous version:
> - rename tee_remoteproc.* file to rmeoteproc_tee.*,
> - rename TEE_REMOTEPROC config to REMOTEPROC_TEE,
> - remove "stm32" in some variable declarations,
> - remove useless "remoteproc_internal.h" include,
> - fix tee_rproc_ctx devm_kzalloc.
> - rework module description
> ---
>  drivers/remoteproc/Kconfig  |  10 +
>  drivers/remoteproc/Makefile |   1 +
>  drivers/remoteproc/remoteproc_tee.c | 446 
>  include/linux/remoteproc.h  |   4 +
>  include/linux/remoteproc_tee.h  | 100 +++
>  5 files changed, 561 insertions(+)
>  create mode 100644 drivers/remoteproc/remoteproc_tee.c
>  create mode 100644 include/linux/remoteproc_tee.h
> 
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index 48845dc8fa85..278f197acb90 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -365,6 +365,16 @@ config XLNX_R5_REMOTEPROC
>  
> It's safe to say N if not interested in using RPU r5f cores.
>  
> +
> +config REMOTEPROC_TEE
> + tristate "Remoteproc support by a TEE application"
> + depends on OPTEE
> + help
> +   Support a remote processor with a TEE application. The Trusted
> +   Execution Context is responsible for loading the trusted firmware
> +   image and managing the remote processor's lifecycle.
> +   This can be either built-in or a loadable module.
> +
>  endif # REMOTEPROC
>  
>  endmenu
> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> index 91314a9b43ce..b4eb37177005 100644
> --- a/drivers/remoteproc/Makefile
> +++ b/drivers/remoteproc/Makefile
> @@ -36,6 +36,7 @@ obj-$(CONFIG_RCAR_REMOTEPROC)   += rcar_rproc.o
>  obj-$(CONFIG_ST_REMOTEPROC)  += st_remoteproc.o
>  obj-$(CONFIG_ST_SLIM_REMOTEPROC) += st_slim_rproc.o
>  obj-$(CONFIG_STM32_RPROC)+= stm32_rproc.o
> +obj-$(CONFIG_REMOTEPROC_TEE) += remoteproc_tee.o
>  obj-$(CONFIG_TI_K3_DSP_REMOTEPROC)   += ti_k3_dsp_remoteproc.o
>  obj-$(CONFIG_TI_K3_R5_REMOTEPROC)+= ti_k3_r5_remoteproc.o
>  obj-$(CONFIG_XLNX_R5_REMOTEPROC) += xlnx_r5_remoteproc.o
> diff --git a/drivers/remoteproc/remoteproc_tee.c 
> b/drivers/remoteproc/remoteproc_tee.c
> new file mode 100644
> index ..70cb67451767
> --- /dev/null
> +++ b/drivers/remoteproc/remoteproc_tee.c
> @@ -0,0 +1,446 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) STMicroelectronics 2024
> + * Author: Arnaud Pouliquen 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define MAX_TEE_PARAM_ARRY_MEMBER4
> +
> +/*
> + * Authentication of the firmware and load in the remote processor memory
> + *
> + * [in]  params[0].value.a:  unique 32bit identifier of the remote processor
> + * [in]   params[1].memref:  buffer containing the image of the 
> buffer
> + */
> +#define TA_RPROC_FW_CMD_LOAD_FW  1
> +
> +/*
> + * Start the remote processor
> + *
> + * [in]  params[0].value.a:  unique 32bit identifier of the remote processor
> + */
> +#define TA_RPROC_FW_CMD_START_FW 2
> +
> +/*
> + * Stop the remote processor
> + *
> + * [in]  params[0].value.a:  unique 32bit identifier of the remote processor
> + */
> +#define TA_RPROC_FW_CMD_STOP_FW  3
> +
> +/*
> + * Return the address of the resource table, or 0 if not found
> + * No check is done to verify that the address returned is accessible by
> + * the non secure context. If the resource table is loaded in a protected
> + * memory the access by the non secure context will lead to a data abort.
> + *
> + * [in]  params[0].value.a:  unique 32bit identifier of the remote processor
> + * [out]  params[1].value.a: 32bit LSB resource table memory address
> + * [out]  params[1].value.b: 32bit MSB resource table memory address
> + * [out]  params[2].value.a: 32bit LSB resource table memory size
> + * [out]  params[2].value.b: 32bit MSB resource table memory size
> + */
> +#define TA_RPROC_FW_CMD_GET_RSC_TABLE4
> +
> +/*
> + * Return the address of the core dump
> + *
> + * [in]  params[0].value.a:  unique 32bit identifier of the remote processor
> + * [out] params[1].memref:   address of the core dump image if exist,
> + *   else return Null
> + */
> +#define TA_RPROC_FW_CMD_GET_COREDUMP 5
> +
> +struct tee_rproc_context {
> + struct list_head sessions;
> + struct tee_context *tee_ctx;
> + struct device *dev;
> +};
> +
> +st

Re: [PATCH 1/4] remoteproc: k3-r5: Fix IPC-only mode detection

[Mathieu Poirier]

On Mon, Jul 01, 2024 at 04:13:00AM -0500, Hari Nagalla wrote:
> On 6/28/24 14:58, Mathieu Poirier wrote:
> > > This could lead in an incorrect IPC-only mode detection if reset line is
> > > asserted (so reset_control_status() return > 0) and c_state != 0 and
> > > halted == 0.
> > > In this case, the old code would have detected an IPC-only mode instead
> > > of a mismatched mode.
> > > 
> > Your assessment seems to be correct.  That said I'd like to have an RB or a 
> > TB
> > from someone in the TI delegation - guys please have a look.
> Agree with Richard's assessment, and the proposed fix looks good.
> 
> Reviewed-by:
> Hari Nagalla 

I have applied this patch, no need to send it again.

Thanks,
Mathieu

Re: [PATCH 3/4] remoteproc: k3-r5: k3_r5_rproc_stop: code reorder

[Mathieu Poirier]

On Mon, Jul 01, 2024 at 10:03:22AM +0200, Richard GENOUD wrote:
> Le 28/06/2024 à 23:18, Mathieu Poirier a écrit :
> > On Fri, Jun 21, 2024 at 05:00:57PM +0200, Richard Genoud wrote:
> > > In the next commit, a RP_MBOX_SHUTDOWN message will be sent in
> > > k3_r5_rproc_stop() to the remote proc (in lockstep on not)
> > > Thus, the sanity check "do not allow core 0 to stop before core 1"
> > > should be moved at the beginning of the function so that the generic case
> > > can be dealt with.
> > > 
> > > In order to have an easier patch to review, those actions are broke in
> > > two patches:
> > > - this patch: moving the sanity check at the beginning (No functional
> > >change).
> > > - next patch: doing the real job (sending shutdown messages to remote
> > >procs before halting them).
> > > 
> > > Basically, we had:
> > > - cluster_mode actions
> > > - !cluster_mode sanity check
> > > - !cluster_mode actions
> > > And now:
> > > - !cluster_mode sanity check
> > > - cluster_mode actions
> > > - !cluster_mode actions
> > > 
> > > Signed-off-by: Richard Genoud 
> > > ---
> > >   drivers/remoteproc/ti_k3_r5_remoteproc.c | 24 ++--
> > >   1 file changed, 14 insertions(+), 10 deletions(-)
> > > 
> > > diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c 
> > > b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> > > index 1f18b08618c8..a2ead87952c7 100644
> > > --- a/drivers/remoteproc/ti_k3_r5_remoteproc.c
> > > +++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> > > @@ -636,16 +636,8 @@ static int k3_r5_rproc_stop(struct rproc *rproc)
> > >   struct k3_r5_core *core1, *core = kproc->core;
> > >   int ret;
> > > - /* halt all applicable cores */
> > > - if (cluster->mode == CLUSTER_MODE_LOCKSTEP) {
> > > - list_for_each_entry(core, &cluster->cores, elem) {
> > > - ret = k3_r5_core_halt(core);
> > > - if (ret) {
> > > - core = list_prev_entry(core, elem);
> > > - goto unroll_core_halt;
> > > - }
> > > - }
> > > - } else {
> > > +
> > > + if (cluster->mode != CLUSTER_MODE_LOCKSTEP) {
> > >   /* do not allow core 0 to stop before core 1 */
> > >   core1 = list_last_entry(&cluster->cores, struct 
> > > k3_r5_core,
> > >   elem);
> > > @@ -656,6 +648,18 @@ static int k3_r5_rproc_stop(struct rproc *rproc)
> > >   ret = -EPERM;
> > >   goto out;
> > >   }
> > > + }
> > > +
> > > + /* halt all applicable cores */
> > > + if (cluster->mode == CLUSTER_MODE_LOCKSTEP) {
> > > + list_for_each_entry(core, &cluster->cores, elem) {
> > > + ret = k3_r5_core_halt(core);
> > > + if (ret) {
> > > + core = list_prev_entry(core, elem);
> > > + goto unroll_core_halt;
> > > + }
> > > + }
> > > + } else {
> > >   ret = k3_r5_core_halt(core);
> > >   if (ret)
> > 
> > With this patch, the "else" in this "if" condition is coupled with the "if" 
> > from
> > the lockstep mode, making the code extremaly hard to read.  The original 
> > code
> > has a k3_r5_core_halt() in both "if" conditions, making the condition
> > independent from one another.
> > 
> I'm not sure I understand what you mean.

With your patch applied I get the following: https://pastebin.com/yTZ0pKcS

Let's say the R5 is in split mode and k3_r5_rproc_stop() called on core1.  The
if() that deal with that condition is on line 10, while the function that halts
the remote processor is online 34, part of the else clause that handles lockstep
mode.  The two if() clauses are entangled and nothing good can come out of that.

> Anyway, I'm not happy with this diff, it doesn't reflect what was intended.
> (which is moving the check "core 0 should not be stop before core 1" at the 
> beginning)
> 
> Tweaking around with the diff algorithms, I came with something way easier to 
> read I think:
> 
> diff --git a/drivers/remoteproc/ti_k3_r5_remotep

Re: [PATCH 0/4] remoteproc: k3-r5: Introduce suspend to ram support

[Mathieu Poirier]

On Fri, 21 Jun 2024 at 09:01, Richard Genoud  wrote:
>
> This series enables the suspend to ram with R5F remote processors on TI K3
> platform.
>
> The 1st patch is actually a fix, independent from the others
>
> The 2nd patch introduces the suspend/resume handlers.
> On suspend, the running rprocs will be stopped (or detached) and then
> re-loaded in resume.
> The logic behind this is:
>  - shutdown the cores that Linux started to save power in suspend.
>  - detach the cores that were started before Linux.
>
> Then, the 3rd and 4th patches introduce the graceful shutdown of remote
> procs. This will give them a chance to release resources and shut down
> in a civilized manner.
>
> Without this series, the suspend fails with:
>
> omap-mailbox 31f81000.mailbox: fifo 1 has unexpected unread messages
> omap-mailbox 31f81000.mailbox: PM: dpm_run_callback(): platform_pm_suspend 
> returns -16
> omap-mailbox 31f81000.mailbox: PM: platform_pm_suspend returned -16 after 
> 16328 usecs
> omap-mailbox 31f81000.mailbox: PM: failed to suspend: error -16
>
> Patches 2 and 4 are based on work from Hari Nagalla .
>
> @Hari, please feel free to add your Co-developed-by:/Signed-off-by:
>
> Tested on J7200X SoM
> Series is based on v6.10-rc4
>
> Richard Genoud (4):
>   remoteproc: k3-r5: Fix IPC-only mode detection
>   remoteproc: k3-r5: Introduce PM suspend/resume handlers
>   remoteproc: k3-r5: k3_r5_rproc_stop: code reorder
>   remoteproc: k3-r5: support for graceful stop of remote cores
>
>  drivers/remoteproc/omap_remoteproc.h |   9 +-
>  drivers/remoteproc/ti_k3_r5_remoteproc.c | 196 +--
>  2 files changed, 188 insertions(+), 17 deletions(-)
>

Nishanth, Vignesh, Hari and Andrew - I will wait for you guys to
review this patch before moving forward.

Thanks,
Mathieu

Re: [PATCH 4/4] remoteproc: k3-r5: support for graceful stop of remote cores

[Mathieu Poirier]

On Fri, Jun 21, 2024 at 05:00:58PM +0200, Richard Genoud wrote:
> Introduce software IPC handshake between the K3-R5 remote proc driver
> and the R5 MCU to gracefully stop/reset the remote core.
> 
> Upon a stop request, K3-R5 remote proc driver sends a RP_MBOX_SHUTDOWN
> mailbox message to the remote R5 core.
> The remote core is expected to:
> - relinquish all the resources acquired through Device Manager (DM)
> - disable its interrupts
> - send back a mailbox acknowledgment RP_MBOX_SHUDOWN_ACK
> - enter WFI state.
> 
> Meanwhile, the K3-R5 remote proc driver does:
> - wait for the RP_MBOX_SHUTDOWN_ACK from the remote core
> - wait for the remote proc to enter WFI state
> - reset the remote core through device manager
> 
> Based on work from: Hari Nagalla 
>

Why is this needed now and what happens to system with a new kernel driver and
an older K3R5 firmware?

Thanks,
Mathieu

> Signed-off-by: Richard Genoud 
> ---
>  drivers/remoteproc/omap_remoteproc.h |  9 +-
>  drivers/remoteproc/ti_k3_r5_remoteproc.c | 40 
>  2 files changed, 48 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/remoteproc/omap_remoteproc.h 
> b/drivers/remoteproc/omap_remoteproc.h
> index 828e13256c02..c008f11fa2a4 100644
> --- a/drivers/remoteproc/omap_remoteproc.h
> +++ b/drivers/remoteproc/omap_remoteproc.h
> @@ -42,6 +42,11 @@
>   * @RP_MBOX_SUSPEND_CANCEL: a cancel suspend response from a remote processor
>   * on a suspend request
>   *
> + * @RP_MBOX_SHUTDOWN: shutdown request for the remote processor
> + *
> + * @RP_MBOX_SHUTDOWN_ACK: successful response from remote processor for a
> + * shutdown request. The remote processor should be in WFI state short after.
> + *
>   * Introduce new message definitions if any here.
>   *
>   * @RP_MBOX_END_MSG: Indicates end of known/defined messages from remote core
> @@ -59,7 +64,9 @@ enum omap_rp_mbox_messages {
>   RP_MBOX_SUSPEND_SYSTEM  = 0xFF11,
>   RP_MBOX_SUSPEND_ACK = 0xFF12,
>   RP_MBOX_SUSPEND_CANCEL  = 0xFF13,
> - RP_MBOX_END_MSG = 0xFF14,
> + RP_MBOX_SHUTDOWN= 0xFF14,
> + RP_MBOX_SHUTDOWN_ACK= 0xFF15,
> + RP_MBOX_END_MSG = 0xFF16,
>  };
>  
>  #endif /* _OMAP_RPMSG_H */
> diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c 
> b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> index a2ead87952c7..918a15e1dd9a 100644
> --- a/drivers/remoteproc/ti_k3_r5_remoteproc.c
> +++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> @@ -21,6 +21,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -172,8 +173,23 @@ struct k3_r5_rproc {
>   struct k3_r5_core *core;
>   struct k3_r5_mem *rmem;
>   int num_rmems;
> + struct completion shutdown_complete;
>  };
>  
> +/*
> + * This will return true if the remote core is in Wait For Interrupt state.
> + */
> +static bool k3_r5_is_core_in_wfi(struct k3_r5_core *core)
> +{
> + int ret;
> + u64 boot_vec;
> + u32 cfg, ctrl, stat;
> +
> + ret = ti_sci_proc_get_status(core->tsp, &boot_vec, &cfg, &ctrl, &stat);
> +
> + return !ret ? !!(stat & PROC_BOOT_STATUS_FLAG_R5_WFI) : false;
> +}
> +
>  /**
>   * k3_r5_rproc_mbox_callback() - inbound mailbox message handler
>   * @client: mailbox client pointer used for requesting the mailbox channel
> @@ -209,6 +225,10 @@ static void k3_r5_rproc_mbox_callback(struct mbox_client 
> *client, void *data)
>   case RP_MBOX_ECHO_REPLY:
>   dev_info(dev, "received echo reply from %s\n", name);
>   break;
> + case RP_MBOX_SHUTDOWN_ACK:
> + dev_dbg(dev, "received shutdown_ack from %s\n", name);
> + complete(&kproc->shutdown_complete);
> + break;
>   default:
>   /* silently handle all other valid messages */
>   if (msg >= RP_MBOX_READY && msg < RP_MBOX_END_MSG)
> @@ -634,6 +654,7 @@ static int k3_r5_rproc_stop(struct rproc *rproc)
>   struct k3_r5_cluster *cluster = kproc->cluster;
>   struct device *dev = kproc->dev;
>   struct k3_r5_core *core1, *core = kproc->core;
> + bool wfi;
>   int ret;
>  
>  
> @@ -650,6 +671,24 @@ static int k3_r5_rproc_stop(struct rproc *rproc)
>   }
>   }
>  
> + /* Send SHUTDOWN message to remote proc */
> + reinit_completion(&kproc->shutdown_complete);
> + ret = mbox_send_message(kproc->mbox, (void *)RP_MBOX_SHUTDOWN);
> + if (ret < 0) {
> + dev_err(dev, "Sending SHUTDOWN message failed: %d. Halting core 
> anyway.\n", ret);
> + } else {
> + ret = wait_for_completion_timeout(&kproc->shutdown_complete,
> +   msecs_to_jiffies(1000));
> + if (ret == 0) {
> + dev_err(dev, "Timeout waiting SHUTDOWN_ACK message. 
> Halting core anyway.\n");
> + } else {
> + ret = readx_poll_timeout(k3_r5_is_core_in_wfi, core,
> +  

Re: [PATCH 3/4] remoteproc: k3-r5: k3_r5_rproc_stop: code reorder

[Mathieu Poirier]

On Fri, Jun 21, 2024 at 05:00:57PM +0200, Richard Genoud wrote:
> In the next commit, a RP_MBOX_SHUTDOWN message will be sent in
> k3_r5_rproc_stop() to the remote proc (in lockstep on not)
> Thus, the sanity check "do not allow core 0 to stop before core 1"
> should be moved at the beginning of the function so that the generic case
> can be dealt with.
> 
> In order to have an easier patch to review, those actions are broke in
> two patches:
> - this patch: moving the sanity check at the beginning (No functional
>   change).
> - next patch: doing the real job (sending shutdown messages to remote
>   procs before halting them).
> 
> Basically, we had:
> - cluster_mode actions
> - !cluster_mode sanity check
> - !cluster_mode actions
> And now:
> - !cluster_mode sanity check
> - cluster_mode actions
> - !cluster_mode actions
> 
> Signed-off-by: Richard Genoud 
> ---
>  drivers/remoteproc/ti_k3_r5_remoteproc.c | 24 ++--
>  1 file changed, 14 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c 
> b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> index 1f18b08618c8..a2ead87952c7 100644
> --- a/drivers/remoteproc/ti_k3_r5_remoteproc.c
> +++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> @@ -636,16 +636,8 @@ static int k3_r5_rproc_stop(struct rproc *rproc)
>   struct k3_r5_core *core1, *core = kproc->core;
>   int ret;
>  
> - /* halt all applicable cores */
> - if (cluster->mode == CLUSTER_MODE_LOCKSTEP) {
> - list_for_each_entry(core, &cluster->cores, elem) {
> - ret = k3_r5_core_halt(core);
> - if (ret) {
> - core = list_prev_entry(core, elem);
> - goto unroll_core_halt;
> - }
> - }
> - } else {
> +
> + if (cluster->mode != CLUSTER_MODE_LOCKSTEP) {
>   /* do not allow core 0 to stop before core 1 */
>   core1 = list_last_entry(&cluster->cores, struct k3_r5_core,
>   elem);
> @@ -656,6 +648,18 @@ static int k3_r5_rproc_stop(struct rproc *rproc)
>   ret = -EPERM;
>   goto out;
>   }
> + }
> +
> + /* halt all applicable cores */
> + if (cluster->mode == CLUSTER_MODE_LOCKSTEP) {
> + list_for_each_entry(core, &cluster->cores, elem) {
> + ret = k3_r5_core_halt(core);
> + if (ret) {
> + core = list_prev_entry(core, elem);
> + goto unroll_core_halt;
> + }
> + }
> + } else {
>  
>   ret = k3_r5_core_halt(core);
>   if (ret)

With this patch, the "else" in this "if" condition is coupled with the "if" from
the lockstep mode, making the code extremaly hard to read.  The original code
has a k3_r5_core_halt() in both "if" conditions, making the condition
independent from one another.

Re: [PATCH 2/4] remoteproc: k3-r5: Introduce PM suspend/resume handlers

[Mathieu Poirier]

On Fri, Jun 21, 2024 at 05:00:56PM +0200, Richard Genoud wrote:
> This patch adds the support for system suspend/resume to the ti_k3_R5
> remoteproc driver.
> 
> In order to save maximum power, the approach here is to shutdown
> completely the cores that were started by the kernel (i.e. those in
> RUNNING state).
> Those which were started before the kernel (in attached mode) will be
> detached.
> 
> The pm_notifier mechanism is used here because the remote procs firmwares
> have to be reloaded at resume, and thus the driver must have access to
> the file system were the firmware is stored.
> 
> On suspend, the running remote procs are stopped, the attached remote
> procs are detached and processor control released.
> 
> On resume, the reverse operation is done.
> 
> Based on work from: Hari Nagalla 
> 
> Signed-off-by: Richard Genoud 
> ---
>  drivers/remoteproc/ti_k3_r5_remoteproc.c | 123 ++-
>  1 file changed, 121 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c 
> b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> index 39a47540c590..1f18b08618c8 100644
> --- a/drivers/remoteproc/ti_k3_r5_remoteproc.c
> +++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -112,6 +113,7 @@ struct k3_r5_cluster {
>   struct list_head cores;
>   wait_queue_head_t core_transition;
>   const struct k3_r5_soc_data *soc_data;
> + struct notifier_block pm_notifier;
>  };
>  
>  /**
> @@ -577,7 +579,8 @@ static int k3_r5_rproc_start(struct rproc *rproc)
>   /* do not allow core 1 to start before core 0 */
>   core0 = list_first_entry(&cluster->cores, struct k3_r5_core,
>elem);
> - if (core != core0 && core0->rproc->state == RPROC_OFFLINE) {
> + if (core != core0 && (core0->rproc->state == RPROC_OFFLINE ||
> +   core0->rproc->state == RPROC_SUSPENDED)) {

If I understand correctly, this is to address a possible race condition between
user space wanting to start core1 via sysfs while the system is being suspended.
Is this correct?  If so, please add a comment to explain what is going on.
Otherwise a comment is obviously needed.

>   dev_err(dev, "%s: can not start core 1 before core 0\n",
>   __func__);
>   ret = -EPERM;
> @@ -646,7 +649,8 @@ static int k3_r5_rproc_stop(struct rproc *rproc)
>   /* do not allow core 0 to stop before core 1 */
>   core1 = list_last_entry(&cluster->cores, struct k3_r5_core,
>   elem);
> - if (core != core1 && core1->rproc->state != RPROC_OFFLINE) {
> + if (core != core1 && core1->rproc->state != RPROC_OFFLINE &&
> + core1->rproc->state != RPROC_SUSPENDED) {
>   dev_err(dev, "%s: can not stop core 0 before core 1\n",
>   __func__);
>   ret = -EPERM;
> @@ -1238,6 +1242,117 @@ static int k3_r5_rproc_configure_mode(struct 
> k3_r5_rproc *kproc)
>   return ret;
>  }
>  
> +static int k3_r5_rproc_suspend(struct k3_r5_rproc *kproc)
> +{
> + unsigned int rproc_state = kproc->rproc->state;
> + int ret;
> +
> + if (rproc_state != RPROC_RUNNING && rproc_state != RPROC_ATTACHED)
> + return 0;
> +
> + if (rproc_state == RPROC_RUNNING)
> + ret = rproc_shutdown(kproc->rproc);
> + else
> + ret = rproc_detach(kproc->rproc);
> +
> + if (ret) {
> + dev_err(kproc->dev, "Failed to %s rproc (%d)\n",
> + (rproc_state == RPROC_RUNNING) ? "shutdown" : "detach",
> + ret);
> + return ret;
> + }
> +
> + kproc->rproc->state = RPROC_SUSPENDED;
> +
> + return ret;
> +}
> +
> +static int k3_r5_rproc_resume(struct k3_r5_rproc *kproc)
> +{
> + int ret;
> +
> + if (kproc->rproc->state != RPROC_SUSPENDED)
> + return 0;
> +
> + ret = k3_r5_rproc_configure_mode(kproc);
> + if (ret < 0)
> + return -EBUSY;
> +
> + /*
> +  * ret > 0 for IPC-only mode
> +  * ret == 0 for remote proc mode
> +  */
> + if (ret == 0) {
> + /*
> +  * remote proc looses its configuration when powered off.
> +  * So, we have to configure it again on resume.
> +  */
> + ret = k3_r5_rproc_configure(kproc);
> + if (ret < 0) {
> + dev_err(kproc->dev, "k3_r5_rproc_configure failed 
> (%d)\n", ret);
> + return -EBUSY;
> + }
> + }
> +
> + return rproc_boot(kproc->rproc);
> +}
> +
> +static int k3_r5_cluster_pm_notifier_call(struct notifier_block *bl,
> +   unsigned long state, void *unused)
> 

Re: [PATCH 1/4] remoteproc: k3-r5: Fix IPC-only mode detection

[Mathieu Poirier]

Nishanth, Vignesh, Hari and Andrew - please have a look at this patch.

Thanks,
Mathieu

On Fri, 28 Jun 2024 at 13:53, Mathieu Poirier
 wrote:
>
> Good day,
>
> On Fri, Jun 21, 2024 at 05:00:55PM +0200, Richard Genoud wrote:
> > ret variable was used to test reset status, get from
> > reset_control_status() call. But this variable was overwritten by
> > ti_sci_proc_get_status() a few lines bellow.
> > And as ti_sci_proc_get_status() returns 0 or a negative value (in this
> > latter case, followed by a return), the expression !ret was always true,
> >
> > Clearly, this was not what was intended:
> > In the comment above it's said that "requires both local and module
> > resets to be deasserted"; if reset_control_status() returns 0 it means
> > that the reset line is deasserted.
> > So, it's pretty clear that the return value of reset_control_status()
> > was intended to be used instead of ti_sci_proc_get_status() return
> > value.
> >
> > This could lead in an incorrect IPC-only mode detection if reset line is
> > asserted (so reset_control_status() return > 0) and c_state != 0 and
> > halted == 0.
> > In this case, the old code would have detected an IPC-only mode instead
> > of a mismatched mode.
> >
>
> Your assessment seems to be correct.  That said I'd like to have an RB or a TB
> from someone in the TI delegation - guys please have a look.
>
> Thanks,
> Mathieu
>
> > Fixes: 1168af40b1ad ("remoteproc: k3-r5: Add support for IPC-only mode for 
> > all R5Fs")
> > Signed-off-by: Richard Genoud 
> > ---
> >  drivers/remoteproc/ti_k3_r5_remoteproc.c | 13 +++--
> >  1 file changed, 7 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c 
> > b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> > index 50e486bcfa10..39a47540c590 100644
> > --- a/drivers/remoteproc/ti_k3_r5_remoteproc.c
> > +++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> > @@ -1144,6 +1144,7 @@ static int k3_r5_rproc_configure_mode(struct 
> > k3_r5_rproc *kproc)
> >   u32 atcm_enable, btcm_enable, loczrama;
> >   struct k3_r5_core *core0;
> >   enum cluster_mode mode = cluster->mode;
> > + int reset_ctrl_status;
> >   int ret;
> >
> >   core0 = list_first_entry(&cluster->cores, struct k3_r5_core, elem);
> > @@ -1160,11 +1161,11 @@ static int k3_r5_rproc_configure_mode(struct 
> > k3_r5_rproc *kproc)
> >r_state, c_state);
> >   }
> >
> > - ret = reset_control_status(core->reset);
> > - if (ret < 0) {
> > + reset_ctrl_status = reset_control_status(core->reset);
> > + if (reset_ctrl_status < 0) {
> >   dev_err(cdev, "failed to get initial local reset status, ret 
> > = %d\n",
> > - ret);
> > - return ret;
> > + reset_ctrl_status);
> > + return reset_ctrl_status;
> >   }
> >
> >   /*
> > @@ -1199,7 +1200,7 @@ static int k3_r5_rproc_configure_mode(struct 
> > k3_r5_rproc *kproc)
> >* irrelevant if module reset is asserted (POR value has local reset
> >* deasserted), and is deemed as remoteproc mode
> >*/
> > - if (c_state && !ret && !halted) {
> > + if (c_state && !reset_ctrl_status && !halted) {
> >   dev_info(cdev, "configured R5F for IPC-only mode\n");
> >   kproc->rproc->state = RPROC_DETACHED;
> >   ret = 1;
> > @@ -1217,7 +1218,7 @@ static int k3_r5_rproc_configure_mode(struct 
> > k3_r5_rproc *kproc)
> >   ret = 0;
> >   } else {
> >   dev_err(cdev, "mismatched mode: local_reset = %s, 
> > module_reset = %s, core_state = %s\n",
> > - !ret ? "deasserted" : "asserted",
> > + !reset_ctrl_status ? "deasserted" : "asserted",
> >   c_state ? "deasserted" : "asserted",
> >   halted ? "halted" : "unhalted");
> >   ret = -EINVAL;

Re: [PATCH 1/4] remoteproc: k3-r5: Fix IPC-only mode detection

[Mathieu Poirier]

Good day,

On Fri, Jun 21, 2024 at 05:00:55PM +0200, Richard Genoud wrote:
> ret variable was used to test reset status, get from
> reset_control_status() call. But this variable was overwritten by
> ti_sci_proc_get_status() a few lines bellow.
> And as ti_sci_proc_get_status() returns 0 or a negative value (in this
> latter case, followed by a return), the expression !ret was always true,
> 
> Clearly, this was not what was intended:
> In the comment above it's said that "requires both local and module
> resets to be deasserted"; if reset_control_status() returns 0 it means
> that the reset line is deasserted.
> So, it's pretty clear that the return value of reset_control_status()
> was intended to be used instead of ti_sci_proc_get_status() return
> value.
> 
> This could lead in an incorrect IPC-only mode detection if reset line is
> asserted (so reset_control_status() return > 0) and c_state != 0 and
> halted == 0.
> In this case, the old code would have detected an IPC-only mode instead
> of a mismatched mode.
> 

Your assessment seems to be correct.  That said I'd like to have an RB or a TB
from someone in the TI delegation - guys please have a look.

Thanks,
Mathieu

> Fixes: 1168af40b1ad ("remoteproc: k3-r5: Add support for IPC-only mode for 
> all R5Fs")
> Signed-off-by: Richard Genoud 
> ---
>  drivers/remoteproc/ti_k3_r5_remoteproc.c | 13 +++--
>  1 file changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c 
> b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> index 50e486bcfa10..39a47540c590 100644
> --- a/drivers/remoteproc/ti_k3_r5_remoteproc.c
> +++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> @@ -1144,6 +1144,7 @@ static int k3_r5_rproc_configure_mode(struct 
> k3_r5_rproc *kproc)
>   u32 atcm_enable, btcm_enable, loczrama;
>   struct k3_r5_core *core0;
>   enum cluster_mode mode = cluster->mode;
> + int reset_ctrl_status;
>   int ret;
>  
>   core0 = list_first_entry(&cluster->cores, struct k3_r5_core, elem);
> @@ -1160,11 +1161,11 @@ static int k3_r5_rproc_configure_mode(struct 
> k3_r5_rproc *kproc)
>r_state, c_state);
>   }
>  
> - ret = reset_control_status(core->reset);
> - if (ret < 0) {
> + reset_ctrl_status = reset_control_status(core->reset);
> + if (reset_ctrl_status < 0) {
>   dev_err(cdev, "failed to get initial local reset status, ret = 
> %d\n",
> - ret);
> - return ret;
> + reset_ctrl_status);
> + return reset_ctrl_status;
>   }
>  
>   /*
> @@ -1199,7 +1200,7 @@ static int k3_r5_rproc_configure_mode(struct 
> k3_r5_rproc *kproc)
>* irrelevant if module reset is asserted (POR value has local reset
>* deasserted), and is deemed as remoteproc mode
>*/
> - if (c_state && !ret && !halted) {
> + if (c_state && !reset_ctrl_status && !halted) {
>   dev_info(cdev, "configured R5F for IPC-only mode\n");
>   kproc->rproc->state = RPROC_DETACHED;
>   ret = 1;
> @@ -1217,7 +1218,7 @@ static int k3_r5_rproc_configure_mode(struct 
> k3_r5_rproc *kproc)
>   ret = 0;
>   } else {
>   dev_err(cdev, "mismatched mode: local_reset = %s, module_reset 
> = %s, core_state = %s\n",
> - !ret ? "deasserted" : "asserted",
> + !reset_ctrl_status ? "deasserted" : "asserted",
>   c_state ? "deasserted" : "asserted",
>   halted ? "halted" : "unhalted");
>   ret = -EINVAL;