Re: [PATCH] remoteproc: xlnx: reset virtio status during attach

[Mathieu Poirier]

On Tue, Mar 17, 2026 at 01:12:51PM -0700, Tanmay Shah wrote:
> On AMD-Xilinx platforms cortex-A and cortex-R can be configured as
> separate subsystems. In this case, both cores can boot independent of
> each other. If Linux went through uncontrolled reboot during active
> rpmsg communication, then during next boot it can find rpmsg virtio
> status not in the reset state. In such case it is important to reset the
> virtio status during attach callback and wait for sometime for the
> remote to handle virtio driver reset.

I understand the user case, but won't that situation happen regardless of
whether cores operate sync or split mode?

> 
> Signed-off-by: Tanmay Shah <tanmay.shah@xxxxxxx>
> ---
>  drivers/remoteproc/xlnx_r5_remoteproc.c | 46 +++++++++++++++++++++++++
>  1 file changed, 46 insertions(+)
> 
> diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c
> index 50a9974f3202..f08806f13800 100644
> --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
> +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
> @@ -5,6 +5,7 @@
>   */
>  
>  #include <dt-bindings/power/xlnx-zynqmp-power.h>
> +#include <linux/delay.h>
>  #include <linux/dma-mapping.h>
>  #include <linux/firmware/xlnx-zynqmp.h>
>  #include <linux/kernel.h>
> @@ -29,6 +30,8 @@
>  #define RSC_TBL_XLNX_MAGIC	((uint32_t)'x' << 24 | (uint32_t)'a' << 16 | \
>  				 (uint32_t)'m' << 8 | (uint32_t)'p')
>  
> +#define RPROC_ATTACH_TIMEOUT_US (100 * 1000)
> +

There are some time constant already defined, please use them.

>  /*
>   * settings for RPU cluster mode which
>   * reflects possible values of xlnx,cluster-mode dt-property
> @@ -865,6 +868,49 @@ static int zynqmp_r5_get_rsc_table_va(struct zynqmp_r5_core *r5_core)
>  
>  static int zynqmp_r5_attach(struct rproc *rproc)
>  {
> +	struct device *dev = &rproc->dev;
> +	bool wait_for_remote = false;
> +	struct fw_rsc_vdev *rsc;
> +	struct fw_rsc_hdr *hdr;
> +	int i, offset, avail;
> +
> +	if (!rproc->table_ptr)
> +		goto attach_success;
> +
> +	for (i = 0; i < rproc->table_ptr->num; i++) {
> +		offset = rproc->table_ptr->offset[i];
> +		hdr = (void *)rproc->table_ptr + offset;
> +		avail = rproc->table_sz - offset - sizeof(*hdr);
> +		rsc = (void *)hdr + sizeof(*hdr);
> +
> +		/* make sure table isn't truncated */
> +		if (avail < 0) {
> +			dev_err(dev, "rsc table is truncated\n");
> +			return -EINVAL;
> +		}
> +
> +		if (hdr->type != RSC_VDEV)
> +			continue;
> +
> +		/*
> +		 * reset vdev status, in case previous run didn't leave it in
> +		 * a clean state.
> +		 */
> +		if (rsc->status) {
> +			rsc->status = 0;
> +			wait_for_remote = true;
> +			break;
> +		}
> +	}
> +
> +	/* kick remote to notify about attach */
> +	rproc->ops->kick(rproc, 0);
> +
> +	/* wait for sometime until remote is ready */
> +	if (wait_for_remote)
> +		usleep_range(100, RPROC_ATTACH_TIMEOUT_US);

Instead of waiting, would it be possible to return -EPROBE_DEFER and let the
driver core retry mechanic do it's work?

Thanks,
Mathieu

> +
> +attach_success:
>  	dev_dbg(&rproc->dev, "rproc %d attached\n", rproc->index);
>  
>  	return 0;
> 
> base-commit: d4ef36fbd57e610d4c334123ce706a2a71187cae
> -- 
> 2.34.1
>