mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Tanmay Shah <tanmay.shah@amd.com>
To: <andersson@kernel.org>, <mathieu.poirier@linaro.org>
Cc: <linux-remoteproc@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>,
	"Tanmay Shah" <tanmay.shah@amd.com>
Subject: [PATCH] remoteproc: xlnx: reset virtio status during attach
Date: Thu, 24 Sep 2026 13:34:09 -0700	[thread overview]
Message-ID: <20260924203409.2484068-1-tanmay.shah@amd.com> (raw)

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. This is platform management firmware configuration to manage
cores. In such a configuration, if Linux went through an 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 the remote to handle virtio device reset. After reset, the remote
is expected to generate the notification to the host or the host will
eventually timeout and continue the normal boot flow.

Assisted-by: LLM
Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
---
 drivers/remoteproc/xlnx_r5_remoteproc.c | 74 +++++++++++++++++++++++++
 1 file changed, 74 insertions(+)

diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c
index 630621288430..6e7e2a5ea83c 100644
--- a/drivers/remoteproc/xlnx_r5_remoteproc.c
+++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
@@ -6,6 +6,7 @@
 
 #include <linux/dma-mapping.h>
 #include <linux/firmware/xlnx-zynqmp.h>
+#include <linux/jiffies.h>
 #include <linux/kernel.h>
 #include <linux/mailbox_client.h>
 #include <linux/mailbox/zynqmp-ipi-message.h>
@@ -15,6 +16,7 @@
 #include <linux/of_reserved_mem.h>
 #include <linux/platform_device.h>
 #include <linux/remoteproc.h>
+#include <linux/wait.h>
 
 #include "remoteproc_internal.h"
 
@@ -33,6 +35,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 (1000 * 1000)
+
 /*
  * settings for RPU cluster mode which
  * reflects possible values of xlnx,cluster-mode dt-property
@@ -167,6 +171,9 @@ struct xlnx_rproc_crash_report {
  * @rsc_tbl_size: resource table size retrieved from remote
  * @pm_domain_id: RPU CPU power domain id
  * @ipi: pointer to mailbox information
+ * @attach_wq: wait queue for attach-time vdev reset acknowledgment
+ * @waiting_for_attach_ack: whether attach is waiting for remote interrupt
+ * @attach_ack: remote interrupt observed while attach wait is active
  */
 struct zynqmp_r5_core {
 	struct xlnx_rproc_crash_report *crash_report;
@@ -181,6 +188,9 @@ struct zynqmp_r5_core {
 	u32 rsc_tbl_size;
 	u32 pm_domain_id;
 	struct mbox_info *ipi;
+	wait_queue_head_t attach_wq;
+	bool waiting_for_attach_ack;
+	bool attach_ack;
 };
 
 /**
@@ -270,10 +280,17 @@ static void handle_event_notified(struct work_struct *work)
 static void zynqmp_r5_mb_rx_cb(struct mbox_client *cl, void *msg)
 {
 	struct zynqmp_ipi_message *ipi_msg, *buf_msg;
+	struct zynqmp_r5_core *r5_core;
 	struct mbox_info *ipi;
 	size_t len;
 
 	ipi = container_of(cl, struct mbox_info, mbox_cl);
+	r5_core = ipi->r5_core;
+
+	if (r5_core && READ_ONCE(r5_core->waiting_for_attach_ack)) {
+		WRITE_ONCE(r5_core->attach_ack, true);
+		wake_up(&r5_core->attach_wq);
+	}
 
 	/* copy data from ipi buffer to r5_core if IPI is buffered. */
 	ipi_msg = (struct zynqmp_ipi_message *)msg;
@@ -820,6 +837,62 @@ static int zynqmp_r5_get_rsc_table_va(struct zynqmp_r5_core *r5_core)
 
 static int zynqmp_r5_attach(struct rproc *rproc)
 {
+	struct zynqmp_r5_core *r5_core = rproc->priv;
+	struct device *dev = &rproc->dev;
+	bool wait_for_remote = false;
+	struct fw_rsc_vdev *rsc;
+	struct fw_rsc_hdr *hdr;
+	int i, offset, avail;
+	long time_left;
+
+	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;
+		}
+	}
+
+	if (wait_for_remote) {
+		WRITE_ONCE(r5_core->attach_ack, false);
+		WRITE_ONCE(r5_core->waiting_for_attach_ack, true);
+	}
+
+	/* kick remote to notify about attach */
+	rproc->ops->kick(rproc, 0);
+
+	if (wait_for_remote) {
+		time_left = wait_event_timeout(r5_core->attach_wq,
+					       READ_ONCE(r5_core->attach_ack),
+					       usecs_to_jiffies(RPROC_ATTACH_TIMEOUT_US));
+		WRITE_ONCE(r5_core->waiting_for_attach_ack, false);
+
+		if (!time_left)
+			dev_warn(dev, "timeout waiting for remote vdev reset ack\n");
+	}
+
+attach_success:
 	dev_dbg(&rproc->dev, "rproc %d attached\n", rproc->index);
 
 	return 0;
@@ -920,6 +993,7 @@ static struct zynqmp_r5_core *zynqmp_r5_alloc_rproc_core(struct device *cdev)
 	r5_core = r5_rproc->priv;
 	r5_core->dev = cdev;
 	r5_core->np = dev_of_node(cdev);
+	init_waitqueue_head(&r5_core->attach_wq);
 	if (!r5_core->np) {
 		dev_err(cdev, "can't get device node for r5 core\n");
 		ret = -EINVAL;

base-commit: 5f639b3018c0026a5341949724b4b921cf3a3d5d
-- 
2.43.0


             reply	other threads:[~2026-09-24 20:34 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-24 20:34 Tanmay Shah [this message]
  -- strict thread matches above, loose matches on Subject: below --
2026-03-17 20:12 Tanmay Shah
2026-03-27 19:58 ` Mathieu Poirier
2026-03-30 18:43   ` Shah, Tanmay
2026-03-31 17:53     ` Mathieu Poirier
2026-04-01 15:23       ` Shah, Tanmay
2026-04-10 19:45         ` Shah, Tanmay

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260924203409.2484068-1-tanmay.shah@amd.com \
    --to=tanmay.shah@amd.com \
    --cc=andersson@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=mathieu.poirier@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®