mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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
> 

  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®