From: Peng Fan <peng.fan@oss.nxp.com>
To: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
Cc: Bjorn Andersson <andersson@kernel.org>,
Mathieu Poirier <mathieu.poirier@linaro.org>,
linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
Andrew Davis <afd@ti.com>
Subject: Re: [PATCH v2 1/2] remoteproc: core: support fixed device index from DT aliases
Date: Wed, 4 Feb 2026 08:57:12 +0800 [thread overview]
Message-ID: <aYKZaDn5Q58xdO94@shlinux89> (raw)
In-Reply-To: <20260128103118.3630078-2-arnaud.pouliquen@foss.st.com>
On Wed, Jan 28, 2026 at 11:31:17AM +0100, Arnaud Pouliquen wrote:
>On systems with multiple remote processors, the remoteproc device
>enumeration is not stable as it depends on the probe ordering.
>As a result, the /sys/class/remoteproc/remoteproc<x> entries do not
>always refer to the same remote processor instance, which complicates
>userspace applications.
>
>Inspired by the SPI implementation, this commit allows board-specific
>numbering to be defined in device tree while still supporting dynamically
>registered remote processors.
>
>For instance, on STM32MP25 Soc this can be used by defining:
>
> aliases {
> rproc0 = &m33_rproc;
> rproc1 = &m0_rproc;
> };
>
>When a "rproc<x>" DT alias is present, use it to assign a fixed
>"/sys/class/remoteproc/remoteproc<x>" entry.
>If no remoteproc alias is defined, keep the legacy index allocation.
>If only some remoteproc instances have an alias, allocate dynamic
>index starting after the highest alias index declared.
>
>Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
Tested this patch on i.MX943-EVK(patches for this platform still in my local)
with dual CM7 and one CM33S:
/sys/devices/platform/imx943-cm70/remoteproc/remoteproc1/firmware
/sys/devices/platform/imx943-cm33s/remoteproc/remoteproc0/firmware
/sys/devices/platform/imx943-cm71/remoteproc/remoteproc2/firmware
Tested-by: Peng Fan <peng.fan@nxp.com>
One nit below:
>---
>V2:
>- Introduces rproc_get_index based on Mathieu Poirier's suggestion.
> An update compared to Mathieu's version is that the call to
> ida_alloc_range is retained if an alias is found for the remote device,
> to balance with ida_free().
>- Rename DT alias stem from "remoteproc" to "rproc" to be consistent with
> keytone driver.
>---
> drivers/remoteproc/remoteproc_core.c | 40 ++++++++++++++++++++++++++--
> include/linux/remoteproc.h | 3 +++
> 2 files changed, 41 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
>index aada2780b343..38d6eb1c9483 100644
>--- a/drivers/remoteproc/remoteproc_core.c
>+++ b/drivers/remoteproc/remoteproc_core.c
>@@ -2433,6 +2433,43 @@ static int rproc_alloc_ops(struct rproc *rproc, const struct rproc_ops *ops)
> return 0;
> }
>
>+/**
>+ * rproc_get_index - assign a unique device index for a remote processor
>+ * @dev: device associated with the remote processor
>+ *
>+ * Look for a static index coming from the "rproc" DT alias
>+ * (e.g. "rproc0"). If none is found, start allocating
>+ * dynamic IDs after the highest alias in use.
>+ *
>+ * Return: a non-negative index on success, or a negative error code on failure.
>+ */
>+static int rproc_get_index(struct device *dev)
>+{
>+ int index;
>+
>+ /* No DT to deal with */
>+ if (!dev->of_node)
>+ goto legacy;
>+
>+ /* See if an alias has been assigned to this remoteproc */
>+ index = of_alias_get_id(dev->of_node, RPROC_ALIAS);
>+ if (index >= 0)
>+ return ida_alloc_range(&rproc_dev_index, index, index,
>+ GFP_KERNEL);
Nit: "return ida_alloc_range"
Regards,
Peng
next prev parent reply other threads:[~2026-02-04 0:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-28 10:31 [PATCH v2 0/2] Support remoteproc fixed device index from DT aliases Arnaud Pouliquen
2026-01-28 10:31 ` [PATCH v2 1/2] remoteproc: core: support " Arnaud Pouliquen
2026-02-04 0:57 ` Peng Fan [this message]
2026-02-04 8:21 ` Arnaud POULIQUEN
2026-01-28 10:31 ` [PATCH v2 2/2] remoteproc: keystone: use RPROC_ALIAS definition Arnaud Pouliquen
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=aYKZaDn5Q58xdO94@shlinux89 \
--to=peng.fan@oss.nxp.com \
--cc=afd@ti.com \
--cc=andersson@kernel.org \
--cc=arnaud.pouliquen@foss.st.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.