From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
Cc: Bjorn Andersson <andersson@kernel.org>,
linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com
Subject: Re: [RFC PATCH] remoteproc: core: support fixed device index from DT aliases
Date: Tue, 27 Jan 2026 10:13:15 -0700 [thread overview]
Message-ID: <aXjyKzINfpwkv2Fi@p14s> (raw)
In-Reply-To: <20260127130555.3211411-1-arnaud.pouliquen@foss.st.com>
Good morning,
On Tue, Jan 27, 2026 at 02:05:55PM +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 {
> remoteproc0 = &m33_rproc;
> remoteproc1 = &m0_rproc;
> };
>
> When a "remoteproc<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>
> ---
> Notes:
>
> - This patch is submitted as an RFC in this first version.
> The main reason is that support for the Cortex-M33 and Cortex-M0 on
> the STM32MP25 SoC is not yet upstream. The primary objective is to
> trigger discussion on the concept; if there is agreement, I can drop
> the RFC tag in a next version.
I think this is a good idea.
>
> - The keystone_remoteproc driver also uses DT aliases. As it uses the
> "rproc" alias only to construct the firmware name, it should remain
> compatible with this change.
But we won't have "rproc" and "remoteproc" as aliases - it will have to be the
former since TI is already using it. I also suggest doing a #define in
include/linux/remoteproc.h. There is a possibility for backward compatibility
issues but we'll have to let the feature in next long enough to find out.
> ---
> drivers/remoteproc/remoteproc_core.c | 25 +++++++++++++++++++++++--
> 1 file changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
> index aada2780b343..8da6c410870a 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -2461,6 +2461,8 @@ struct rproc *rproc_alloc(struct device *dev, const char *name,
> const char *firmware, int len)
> {
> struct rproc *rproc;
> + int index = -ENODEV;
> + int first_dynamic;
>
> if (!dev || !name || !ops)
> return NULL;
> @@ -2481,8 +2483,27 @@ struct rproc *rproc_alloc(struct device *dev, const char *name,
> rproc->dev.driver_data = rproc;
> idr_init(&rproc->notifyids);
>
> - /* Assign a unique device index and name */
> - rproc->index = ida_alloc(&rproc_dev_index, GFP_KERNEL);
rproc->index = rproc_get_index(dev);
> + /*
> + * Assign a unique device index and name
> + * Look for a static index coming from the "remoteproc" DT alias
> + * (e.g. "remoteproc0"). If none is found, start allocating
> + * dynamic IDs after the highest alias in use.
> + */
> + if (dev->of_node)
> + index = of_alias_get_id(dev->of_node, "remoteproc");
> + if (index < 0) {
> + first_dynamic = of_alias_get_highest_id("remoteproc");
> + if (first_dynamic < 0)
> + first_dynamic = 0;
> + else
> + first_dynamic++;
> + rproc->index = ida_alloc_range(&rproc_dev_index, first_dynamic,
> + ~0, GFP_KERNEL);
> + } else {
> + rproc->index = ida_alloc_range(&rproc_dev_index, index,
> + index, GFP_KERNEL);
> + }
> +
I find the above hard to read and even harder to maintain. I suggest spinning
off a new function as depicted here:
>>>>>>>>>>>>>>>
/*
* Assign a unique device index and name
* 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.
*/
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 index;
/*
* No alias has been assigned to this remoteproc. See if any
* "rproc" aliases have been assigned and start allocating after
* the highest one if it is the case.
*/
index = of_alias_get_highest_id(RPROC_ALIAS);
if (index >= 0)
return = ida_alloc_range(&rproc_dev_index, index + 1,
~0, GFP_KERNEL);
legacy:
return ida_alloc(&rproc_dev_index, GFP_KERNEL);
}
<<<<<<<<<<<<<<<
> if (rproc->index < 0) {
> dev_err(dev, "ida_alloc failed: %d\n", rproc->index);
> goto put_device;
>
> base-commit: 63804fed149a6750ffd28610c5c1c98cce6bd377
> --
> 2.43.0
>
next prev parent reply other threads:[~2026-01-27 17:13 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-27 13:05 Arnaud Pouliquen
2026-01-27 17:13 ` Mathieu Poirier [this message]
2026-01-27 17:48 ` 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=aXjyKzINfpwkv2Fi@p14s \
--to=mathieu.poirier@linaro.org \
--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 \
/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®