[PATCH v3 0/2] remoteproc: xlnx: add auto-boot support

[PATCH v3 0/2] remoteproc: xlnx: add auto-boot support

[Tanmay Shah]

The Linux kernel remoteproc framework provides auto boot feature. When
enabled, the remote processor framework attempts to start the remote
processor based on the firmware-name provided in the device-tree or
attach to the remote processor if bootloader has already started the
remote processor. Enable this auto boot feature for all AMD-xilinx
platforms.

Changes in v3:
  - add more descriptive commit message in the patch 2/2.

Changes in v2:
  - remove the auto-boot property from bindings patch (1/2)
  - rebase on latest remoteproc for-next branch
  - refactor the driver patch (2/2) and detect the auto-boot runtime


Tanmay Shah (2):
  dt-bindings: remoteproc: xlnx: add firmware-name property
  remoteproc: xlnx: enable auto boot feature

 .../remoteproc/xlnx,zynqmp-r5fss.yaml         |  4 ++
 drivers/remoteproc/xlnx_r5_remoteproc.c       | 48 +++++++++++++------
 2 files changed, 38 insertions(+), 14 deletions(-)


base-commit: 90de217305800ff32df4c0308e240925c8deb385
-- 
2.34.1

[PATCH v3 1/2] dt-bindings: remoteproc: xlnx: add firmware-name property

[Tanmay Shah]

The firmware-name property indicates which firmware to load on RPU
during the Linux boot time. It is possible to stop the RPU after boot
and load different firmware and start RPU.

Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
 .../devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml     | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
index ee63c03949c9..ae63c3e39ced 100644
--- a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
@@ -135,6 +135,10 @@ patternProperties:
           - description: vring1
         additionalItems: true
 
+      firmware-name:
+        maxItems: 1
+        description: default firmware to load
+
     required:
       - compatible
       - reg
-- 
2.34.1

[PATCH v3 2/2] remoteproc: xlnx: enable auto boot feature

[Tanmay Shah]

The remoteproc framework has capability to start (or attach to) the remote
processor automatically if auto boot flag is set by the driver during
probe. If the 'firmware-name' property is available for the remoteproc
node, then that firmware will be loaded and started during auto boot. If
the remote core is started by the bootloader then during auto-boot
remoteproc framework will try to attach to the remote processor.

The current architecture allocates and adds the remoteproc instance before
all the hardware such as sram, mbox, TCM is initialized. This design has
to be changed for auto boot to work. So, rename zynqmp_r5_rproc_add()
function to zynqmp_r5_rproc_alloc() and move adding the remoteproc
instance at the end of cluster initialization. This makes sure that all
the required hardware is initialized before starting the remote
processor.

Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
---

Changes in v3:
  - add more descriptive commit message

 drivers/remoteproc/xlnx_r5_remoteproc.c | 48 +++++++++++++++++--------
 1 file changed, 34 insertions(+), 14 deletions(-)

diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c
index 45a62cb98072..652030f9cea2 100644
--- a/drivers/remoteproc/xlnx_r5_remoteproc.c
+++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
@@ -899,17 +899,18 @@ static const struct rproc_ops zynqmp_r5_rproc_ops = {
 };
 
 /**
- * zynqmp_r5_add_rproc_core() - Add core data to framework.
- * Allocate and add struct rproc object for each r5f core
+ * zynqmp_r5_alloc_rproc_core() - alloc rproc core data structure
+ * Allocate struct rproc object for each r5f core
  * This is called for each individual r5f core
  *
  * @cdev: Device node of each r5 core
  *
  * Return: zynqmp_r5_core object for success else error code pointer
  */
-static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
+static struct zynqmp_r5_core *zynqmp_r5_alloc_rproc_core(struct device *cdev)
 {
 	struct zynqmp_r5_core *r5_core;
+	const char *fw_name = NULL;
 	struct rproc *r5_rproc;
 	int ret;
 
@@ -918,10 +919,15 @@ static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
 	if (ret)
 		return ERR_PTR(ret);
 
+	ret = rproc_of_parse_firmware(cdev, 0, &fw_name);
+	if (ret < 0 && ret != -EINVAL)
+		return ERR_PTR(dev_err_probe(cdev, ret,
+					     "failed to parse firmware-name\n"));
+
 	/* Allocate remoteproc instance */
 	r5_rproc = rproc_alloc(cdev, dev_name(cdev),
 			       &zynqmp_r5_rproc_ops,
-			       NULL, sizeof(struct zynqmp_r5_core));
+			       fw_name, sizeof(struct zynqmp_r5_core));
 	if (!r5_rproc) {
 		dev_err(cdev, "failed to allocate memory for rproc instance\n");
 		return ERR_PTR(-ENOMEM);
@@ -932,6 +938,11 @@ static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
 	r5_rproc->recovery_disabled = true;
 	r5_rproc->has_iommu = false;
 	r5_rproc->auto_boot = false;
+
+	/* attempt to boot automatically if the firmware-name is provided */
+	if (fw_name)
+		r5_rproc->auto_boot = true;
+
 	r5_core = r5_rproc->priv;
 	r5_core->dev = cdev;
 	r5_core->np = dev_of_node(cdev);
@@ -941,13 +952,6 @@ static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
 		goto free_rproc;
 	}
 
-	/* Add R5 remoteproc core */
-	ret = rproc_add(r5_rproc);
-	if (ret) {
-		dev_err(cdev, "failed to add r5 remoteproc\n");
-		goto free_rproc;
-	}
-
 	r5_core->rproc = r5_rproc;
 	return r5_core;
 
@@ -1280,6 +1284,7 @@ static int zynqmp_r5_core_init(struct zynqmp_r5_cluster *cluster,
 			if (zynqmp_r5_get_rsc_table_va(r5_core))
 				dev_dbg(r5_core->dev, "rsc tbl not found\n");
 			r5_core->rproc->state = RPROC_DETACHED;
+			r5_core->rproc->auto_boot = true;
 		}
 	}
 
@@ -1304,7 +1309,7 @@ static int zynqmp_r5_cluster_init(struct zynqmp_r5_cluster *cluster)
 	enum rpu_oper_mode fw_reg_val;
 	struct device **child_devs;
 	enum rpu_tcm_comb tcm_mode;
-	int core_count, ret, i;
+	int core_count, ret, i, j;
 	struct mbox_info *ipi;
 
 	ret = of_property_read_u32(dev_node, "xlnx,cluster-mode", &cluster_mode);
@@ -1390,7 +1395,7 @@ static int zynqmp_r5_cluster_init(struct zynqmp_r5_cluster *cluster)
 		child_devs[i] = &child_pdev->dev;
 
 		/* create and add remoteproc instance of type struct rproc */
-		r5_cores[i] = zynqmp_r5_add_rproc_core(&child_pdev->dev);
+		r5_cores[i] = zynqmp_r5_alloc_rproc_core(&child_pdev->dev);
 		if (IS_ERR(r5_cores[i])) {
 			ret = PTR_ERR(r5_cores[i]);
 			r5_cores[i] = NULL;
@@ -1435,16 +1440,31 @@ static int zynqmp_r5_cluster_init(struct zynqmp_r5_cluster *cluster)
 		goto release_r5_cores;
 	}
 
+	for (j = 0; j < cluster->core_count; j++) {
+		/* Add R5 remoteproc core */
+		ret = rproc_add(r5_cores[j]->rproc);
+		if (ret) {
+			dev_err_probe(r5_cores[j]->dev, ret,
+				      "failed to add remoteproc\n");
+			goto delete_r5_cores;
+		}
+	}
+
 	kfree(child_devs);
 	return 0;
 
+delete_r5_cores:
+	i = core_count - 1;
+	/* delete previous added rproc */
+	while (--j >= 0)
+		rproc_del(r5_cores[j]->rproc);
+
 release_r5_cores:
 	while (i >= 0) {
 		put_device(child_devs[i]);
 		if (r5_cores[i]) {
 			zynqmp_r5_free_mbox(r5_cores[i]->ipi);
 			of_reserved_mem_device_release(r5_cores[i]->dev);
-			rproc_del(r5_cores[i]->rproc);
 			rproc_free(r5_cores[i]->rproc);
 		}
 		i--;
-- 
2.34.1

Re: [PATCH v3 2/2] remoteproc: xlnx: enable auto boot feature

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:

New issues:
- [Critical] Dereferencing r5_cores[j]->dev and calling rproc_free() after rproc_add() fails causes a Use-After-Free and Double-Free.

Pre-existing issues:
- [Critical] The driver blindly trusts a physical address and size provided by the remote processor in shared memory.
- [High] The driver frees the mailbox information structure without canceling the associated background workqueue.
- [High] Data race on shared IPI transmit buffer ipi->tx_mc_buf during remoteproc kick.
- [High] A TOCTOU race condition exists between counting available DT child nodes and iterating over them, leading to a heap buffer overflow.
--

commit 0aa3216df858c52c70549e4af6feda736a8dcc9b
Author: Tanmay Shah <tanmay.shah@amd.com>

remoteproc: xlnx: enable auto boot feature

The remoteproc framework has capability to start (or attach to) the remote
processor automatically if auto boot flag is set by the driver during
probe. This patch delays adding the remoteproc instance until the end of
cluster initialization to ensure all hardware is initialized before starting
the remote processor.

> diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c
> index 45a62cb980725..652030f9cea20 100644
> --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
> +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
[ ... ]
> @@ -1280,6 +1284,7 @@ static int zynqmp_r5_core_init(struct zynqmp_r5_cluster *cluster,
>  			if (zynqmp_r5_get_rsc_table_va(r5_core))

[Severity: Critical]
This is a pre-existing issue, but does zynqmp_r5_get_rsc_table_va() blindly
trust the physical address and size provided by the remote processor in shared
memory?

The driver reads the resource table address and size from a shared memory
region and passes this unvalidated physical address directly to ioremap_wc().
Could a compromised remote processor supply the physical address of sensitive
host kernel memory, allowing it to overwrite arbitrary host memory and
escalate privileges when the host kernel writes status updates into it?

>  				dev_dbg(r5_core->dev, "rsc tbl not found\n");
>  			r5_core->rproc->state = RPROC_DETACHED;
> +			r5_core->rproc->auto_boot = true;
>  		}
>  	}
[ ... ]
> @@ -1304,7 +1309,7 @@ static int zynqmp_r5_cluster_init(struct zynqmp_r5_cluster *cluster)
>  	enum rpu_oper_mode fw_reg_val;
>  	struct device **child_devs;
>  	enum rpu_tcm_comb tcm_mode;
> -	int core_count, ret, i;
> +	int core_count, ret, i, j;
>  	struct mbox_info *ipi;

[Severity: High]
This is a pre-existing issue, but is there a race condition between
counting the available child nodes and iterating over them?

The driver allocates arrays based on the initial count from
of_get_available_child_count(), and then iterates over the child nodes
using for_each_available_child_of_node_scoped().

Since the device tree lock is not held across both operations, could
concurrent modifications (like applying an overlay) cause the loop to yield
more child nodes than initially allocated, overflowing the arrays?

[Severity: High]
This is a pre-existing issue, but is there a data race on the shared IPI
transmit buffer (ipi->tx_mc_buf) during a remoteproc kick?

In zynqmp_r5_rproc_kick(), the virtqueue ID is written to the shared buffer
before calling mbox_send_message(). Since there is no internal locking to
serialize kicks, could concurrent calls from different threads kicking
different virtqueues race on this buffer and overwrite the virtqueue ID before
it is transmitted?

[ ... ]
> @@ -1435,16 +1440,31 @@ static int zynqmp_r5_cluster_init(struct zynqmp_r5_cluster *cluster)
>  		goto release_r5_cores;
>  	}
>  
> +	for (j = 0; j < cluster->core_count; j++) {
> +		/* Add R5 remoteproc core */
> +		ret = rproc_add(r5_cores[j]->rproc);
> +		if (ret) {
> +			dev_err_probe(r5_cores[j]->dev, ret,
> +				      "failed to add remoteproc\n");

[Severity: Critical]
If rproc_add() fails, it drops the initial reference count to 0 and
frees the rproc object, which also frees the appended private data
(r5_cores[j]). Does logging the failure with r5_cores[j]->dev cause a
use-after-free here?

> +			goto delete_r5_cores;
> +		}
> +	}
> +
>  	kfree(child_devs);
>  	return 0;
>  
> +delete_r5_cores:
> +	i = core_count - 1;
> +	/* delete previous added rproc */
> +	while (--j >= 0)
> +		rproc_del(r5_cores[j]->rproc);
> +
>  release_r5_cores:
>  	while (i >= 0) {
>  		put_device(child_devs[i]);
>  		if (r5_cores[i]) {
>  			zynqmp_r5_free_mbox(r5_cores[i]->ipi);

[Severity: High]
This is a pre-existing issue, but if an error occurs and we clean up by
calling zynqmp_r5_free_mbox(), the driver frees the ipi structure without
canceling the associated background workqueue (ipi->mbox_work).

If the remote processor is already running and sends a message, scheduling the
work, will the system workqueue subsequently execute the pending work and
dereference the freed ipi object?

>  			of_reserved_mem_device_release(r5_cores[i]->dev);
> -			rproc_del(r5_cores[i]->rproc);
>  			rproc_free(r5_cores[i]->rproc);

[Severity: Critical]
Additionally, since the rproc object was already freed by rproc_add()
on failure, will jumping to delete_r5_cores and then release_r5_cores
lead to a double-free when it calls rproc_free(r5_cores[i]->rproc)?

>  		}
>  		i--;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260527051611.194844-1-tanmay.shah@amd.com?part=2

Re: [PATCH v3 0/2] remoteproc: xlnx: add auto-boot support

[Mathieu Poirier]

On Tue, May 26, 2026 at 10:16:09PM -0700, Tanmay Shah wrote:
> The Linux kernel remoteproc framework provides auto boot feature. When
> enabled, the remote processor framework attempts to start the remote
> processor based on the firmware-name provided in the device-tree or
> attach to the remote processor if bootloader has already started the
> remote processor. Enable this auto boot feature for all AMD-xilinx
> platforms.
> 
> Changes in v3:
>   - add more descriptive commit message in the patch 2/2.
> 
> Changes in v2:
>   - remove the auto-boot property from bindings patch (1/2)
>   - rebase on latest remoteproc for-next branch
>   - refactor the driver patch (2/2) and detect the auto-boot runtime
> 
> 
> Tanmay Shah (2):
>   dt-bindings: remoteproc: xlnx: add firmware-name property
>   remoteproc: xlnx: enable auto boot feature
> 
>  .../remoteproc/xlnx,zynqmp-r5fss.yaml         |  4 ++
>  drivers/remoteproc/xlnx_r5_remoteproc.c       | 48 +++++++++++++------
>  2 files changed, 38 insertions(+), 14 deletions(-)
> 

Applied.

Thanks,
Mathieu

> 
> base-commit: 90de217305800ff32df4c0308e240925c8deb385
> -- 
> 2.34.1
>