From: Beleswar Padhi <b-padhi@ti.com>
To: <andersson@kernel.org>, <mathieu.poirier@linaro.org>
Cc: <afd@ti.com>, <hnagalla@ti.com>, <u-kumar1@ti.com>,
<p.zabel@pengutronix.de>, <jan.kiszka@siemens.com>,
<christophe.jaillet@wanadoo.fr>, <jkangas@redhat.com>,
<eballetbo@redhat.com>, <b-padhi@ti.com>,
<linux-remoteproc@vger.kernel.org>,
<linux-kernel@vger.kernel.org>
Subject: [PATCH v8 01/20] remoteproc: k3-m4: Prevent Mailbox level IPC with detached core
Date: Fri, 3 Jan 2025 15:42:12 +0530 [thread overview]
Message-ID: <20250103101231.1508151-2-b-padhi@ti.com> (raw)
In-Reply-To: <20250103101231.1508151-1-b-padhi@ti.com>
Inter-Processor Communication is facilitated through mailbox payloads,
which typically contains the index of the triggered virtqueue having the
actual data to be consumed, but the payload can also be used for trivial
communication, like sending an echo message or notifying a crash etc.
When the core is detached, the virtqueues are freed, and thus the Virtio
level IPC is not functional. However, Mailbox IPC is still possible with
trivial payloads.
Therefore, introduce checks in k3_m4_rproc_kick() and
k3_m4_rproc_mbox_callback() functions to return early without parsing
the payload when core is detached, and is not undergoing an attach
operation in IPC-only mode.
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
---
drivers/remoteproc/ti_k3_m4_remoteproc.c | 41 ++++++++++++++++++++----
1 file changed, 35 insertions(+), 6 deletions(-)
diff --git a/drivers/remoteproc/ti_k3_m4_remoteproc.c b/drivers/remoteproc/ti_k3_m4_remoteproc.c
index a16fb165fced..3201c3684a86 100644
--- a/drivers/remoteproc/ti_k3_m4_remoteproc.c
+++ b/drivers/remoteproc/ti_k3_m4_remoteproc.c
@@ -50,6 +50,7 @@ struct k3_m4_rproc_mem_data {
/**
* struct k3_m4_rproc - k3 remote processor driver structure
* @dev: cached device pointer
+ * @rproc: remoteproc device handle
* @mem: internal memory regions data
* @num_mems: number of internal memory regions
* @rmem: reserved memory regions data
@@ -60,9 +61,11 @@ struct k3_m4_rproc_mem_data {
* @ti_sci_id: TI-SCI device identifier
* @mbox: mailbox channel handle
* @client: mailbox client to request the mailbox channel
+ * @is_attach_ongoing: flag to indicate if IPC-only "attach()" is in progress
*/
struct k3_m4_rproc {
struct device *dev;
+ struct rproc *rproc;
struct k3_m4_rproc_mem *mem;
int num_mems;
struct k3_m4_rproc_mem *rmem;
@@ -73,6 +76,7 @@ struct k3_m4_rproc {
u32 ti_sci_id;
struct mbox_chan *mbox;
struct mbox_client client;
+ bool is_attach_ongoing;
};
/**
@@ -93,8 +97,16 @@ static void k3_m4_rproc_mbox_callback(struct mbox_client *client, void *data)
{
struct device *dev = client->dev;
struct rproc *rproc = dev_get_drvdata(dev);
+ struct k3_m4_rproc *kproc = rproc->priv;
u32 msg = (u32)(uintptr_t)(data);
+ /*
+ * Do not forward messages from a detached core, except when the core
+ * is in the process of being attached in IPC-only mode.
+ */
+ if (!kproc->is_attach_ongoing && kproc->rproc->state == RPROC_DETACHED)
+ return;
+
dev_dbg(dev, "mbox msg: 0x%x\n", msg);
switch (msg) {
@@ -135,6 +147,12 @@ static void k3_m4_rproc_kick(struct rproc *rproc, int vqid)
u32 msg = (u32)vqid;
int ret;
+ /*
+ * Do not forward messages to a detached core, except when the core
+ * is in the process of being attached in IPC-only mode.
+ */
+ if (!kproc->is_attach_ongoing && kproc->rproc->state == RPROC_DETACHED)
+ return;
/*
* Send the index of the triggered virtqueue in the mailbox payload.
* NOTE: msg is cast to uintptr_t to prevent compiler warnings when
@@ -515,15 +533,19 @@ static int k3_m4_rproc_stop(struct rproc *rproc)
/*
* 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.
+ * This rproc attach callback only needs to set the "is_attach_ongoing" flag to
+ * notify k3_m4_rproc_{kick/mbox_callback} functions that the core is in the
+ * process of getting attached in 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;
+ kproc->is_attach_ongoing = true;
+
ret = k3_m4_rproc_ping_mbox(kproc);
if (ret)
return ret;
@@ -534,12 +556,18 @@ static int k3_m4_rproc_attach(struct rproc *rproc)
/*
* 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.
+ * This rproc detach callback performs the opposite operation to attach callback
+ * and only needs to clear the "is_attach_ongoing" flag to ensure no mailbox
+ * messages are sent to or received from a detached core. 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)
{
+ struct k3_m4_rproc *kproc = rproc->priv;
+
+ kproc->is_attach_ongoing = false;
+
return 0;
}
@@ -577,6 +605,7 @@ static int k3_m4_rproc_probe(struct platform_device *pdev)
rproc->has_iommu = false;
rproc->recovery_disabled = true;
kproc = rproc->priv;
+ kproc->rproc = rproc;
kproc->dev = dev;
platform_set_drvdata(pdev, rproc);
--
2.34.1
next prev parent reply other threads:[~2025-01-03 10:12 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-03 10:12 [PATCH v8 00/20] Refactor TI K3 DSP and M4 Drivers Beleswar Padhi
2025-01-03 10:12 ` Beleswar Padhi [this message]
2025-01-08 8:49 ` [PATCH v8 01/20] remoteproc: k3-m4: Prevent Mailbox level IPC with detached core Beleswar Prasad Padhi
2025-01-03 10:12 ` [PATCH v8 02/20] remoteproc: k3: Refactor shared data structures Beleswar Padhi
2025-01-03 10:12 ` [PATCH v8 03/20] remoteproc: k3: Refactor mailbox rx_callback functions into common driver Beleswar Padhi
2025-01-03 10:12 ` [PATCH v8 04/20] remoteproc: k3: Refactor .kick rproc ops " Beleswar Padhi
2025-01-03 10:12 ` [PATCH v8 05/20] remoteproc: k3-m4: Use k3_rproc_mem_data structure for memory info Beleswar Padhi
2025-01-03 10:12 ` [PATCH v8 06/20] remoteproc: k3: Refactor rproc_reset() implementation into common driver Beleswar Padhi
2025-01-03 10:12 ` [PATCH v8 07/20] remoteproc: k3: Refactor rproc_release() " Beleswar Padhi
2025-01-03 10:12 ` [PATCH v8 08/20] remoteproc: k3: Refactor rproc_request_mbox() implementations " Beleswar Padhi
2025-01-03 10:12 ` [PATCH v8 09/20] remoteproc: k3: Refactor .prepare rproc ops " Beleswar Padhi
2025-01-03 10:12 ` [PATCH v8 10/20] remoteproc: k3: Refactor .unprepare " Beleswar Padhi
2025-01-03 10:12 ` [PATCH v8 11/20] remoteproc: k3: Refactor .start " Beleswar Padhi
2025-01-03 10:12 ` [PATCH v8 12/20] remoteproc: k3: Refactor .stop " Beleswar Padhi
2025-01-03 10:12 ` [PATCH v8 13/20] remoteproc: k3: Refactor .attach " Beleswar Padhi
2025-01-03 10:12 ` [PATCH v8 14/20] remoteproc: k3: Refactor .detach " Beleswar Padhi
2025-01-03 10:12 ` [PATCH v8 15/20] remoteproc: k3: Refactor .get_loaded_rsc_table " Beleswar Padhi
2025-01-03 10:12 ` [PATCH v8 16/20] remoteproc: k3: Refactor .da_to_va rproc " Beleswar Padhi
2025-01-03 10:12 ` [PATCH v8 17/20] remoteproc: k3: Refactor of_get_memories() functions " Beleswar Padhi
2025-01-03 10:12 ` [PATCH v8 18/20] remoteproc: k3: Refactor mem_release() " Beleswar Padhi
2025-01-03 10:12 ` [PATCH v8 19/20] remoteproc: k3: Refactor reserved_mem_init() " Beleswar Padhi
2025-01-03 10:12 ` [PATCH v8 20/20] remoteproc: k3: Refactor release_tsp() " Beleswar Padhi
2025-01-03 10:50 ` [PATCH v8 00/20] Refactor TI K3 DSP and M4 Drivers Beleswar Prasad Padhi
2025-01-08 15:03 ` Andrew Davis
2025-01-10 14:56 ` Beleswar Prasad Padhi
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=20250103101231.1508151-2-b-padhi@ti.com \
--to=b-padhi@ti.com \
--cc=afd@ti.com \
--cc=andersson@kernel.org \
--cc=christophe.jaillet@wanadoo.fr \
--cc=eballetbo@redhat.com \
--cc=hnagalla@ti.com \
--cc=jan.kiszka@siemens.com \
--cc=jkangas@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=mathieu.poirier@linaro.org \
--cc=p.zabel@pengutronix.de \
--cc=u-kumar1@ti.com \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).