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-by: Peng Fan <peng.fan@nxp.com>
---
V3:
- fix double space typo
- add Peng Fan's Tested-by

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..4a02814c5d04 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);
+	/*
+	 * No alias has been assigned to this remoteproc device. 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);
+}
+
 /**
  * rproc_alloc() - allocate a remote processor handle
  * @dev: the underlying device
@@ -2481,8 +2518,7 @@ 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);
 	if (rproc->index < 0) {
 		dev_err(dev, "ida_alloc failed: %d\n", rproc->index);
 		goto put_device;
diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
index b4795698d8c2..3feb2456ecc4 100644
--- a/include/linux/remoteproc.h
+++ b/include/linux/remoteproc.h
@@ -503,6 +503,9 @@ enum rproc_features {
 	RPROC_MAX_FEATURES,
 };
 
+ /* device tree remoteproc Alias stem */
+ #define RPROC_ALIAS "rproc"
+
 /**
  * struct rproc - represents a physical remote processor device
  * @node: list node of this rproc object
-- 
2.43.0

On 2/4/26 4:52 AM, 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.
> 

While I will agree it is slightly more complicated in userspace to lookup
the device by name string rather than by some static number, there seems to
be a good reason for not doing this also.

Much like network interfaces where the /dev/eth<x> can change each boot and
attempts to make that static from kernel has been turned down: having static
indexes doesn't make userspace software any more portable.

Say you lock your M33 core to rproc<1> on one SoC, it doesn't mean your next
SoC will have the same rproc order, or even have a M33 at all. So you still
need your userspace code to lookup and check the name, otherwise you make
bad assumptions. Not having static IDs forces software to do the correct
thing here.

The only valid reason I can think up is maybe this makes board specific
documentation easier. One can say:

"On the STM32MP257F-DK, check that the M33 has booted by running
`cat /sys/class/remoteproc/remoteproc3/status`"

without having to first find the right number by checking each
`remoteproc<x>/name`. But wouldn't adding something like a named
sysfs dir syslinks work even better?

`cat /sys/class/remoteproc/m33@76000000/status`

(and yes I know someone here at TI did this alias naming for our
keystone platforms, but if not for possible backwards compat breaks
I'd love to remove that one also)

Andrew

> 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-by: Peng Fan <peng.fan@nxp.com>
> ---
> V3:
> - fix double space typo
> - add Peng Fan's Tested-by
> 
> 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..4a02814c5d04 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);
> +	/*
> +	 * No alias has been assigned to this remoteproc device. 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);
> +}
> +
>   /**
>    * rproc_alloc() - allocate a remote processor handle
>    * @dev: the underlying device
> @@ -2481,8 +2518,7 @@ 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);
>   	if (rproc->index < 0) {
>   		dev_err(dev, "ida_alloc failed: %d\n", rproc->index);
>   		goto put_device;
> diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
> index b4795698d8c2..3feb2456ecc4 100644
> --- a/include/linux/remoteproc.h
> +++ b/include/linux/remoteproc.h
> @@ -503,6 +503,9 @@ enum rproc_features {
>   	RPROC_MAX_FEATURES,
>   };
>   
> + /* device tree remoteproc Alias stem */
> + #define RPROC_ALIAS "rproc"
> +
>   /**
>    * struct rproc - represents a physical remote processor device
>    * @node: list node of this rproc object

Hello,

On 2/4/26 15:57, Andrew Davis wrote:
> On 2/4/26 4:52 AM, 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.
>>
> 
> While I will agree it is slightly more complicated in userspace to lookup
> the device by name string rather than by some static number, there seems to
> be a good reason for not doing this also.
> 
> Much like network interfaces where the /dev/eth<x> can change each boot and
> attempts to make that static from kernel has been turned down: having 
> static
> indexes doesn't make userspace software any more portable.
> 
> Say you lock your M33 core to rproc<1> on one SoC, it doesn't mean your 
> next
> SoC will have the same rproc order, or even have a M33 at all. So you still
> need your userspace code to lookup and check the name, otherwise you make
> bad assumptions. Not having static IDs forces software to do the correct
> thing here.

That was also my initial approach, but it is difficult to impose on our 
customers who have legacy applications, especially since they are 
accustomed to using fixed indexes with other framework ABIs.

> 
> The only valid reason I can think up is maybe this makes board specific
> documentation easier. One can say:
> 
> "On the STM32MP257F-DK, check that the M33 has booted by running
> `cat /sys/class/remoteproc/remoteproc3/status`"
> 
> without having to first find the right number by checking each
> `remoteproc<x>/name`. But wouldn't adding something like a named
> sysfs dir syslinks work even better?
> 
> `cat /sys/class/remoteproc/m33@76000000/status`

The only benefit I can see in checking 
/sys/class/remoteproc/<name>/status instead of 
/sys/class/remoteproc/remoteproc<x>/name is to avoid iterating over 
devices by name. However, in both cases, the application still needs to 
know the remote processor name, which is platform-dependent and usually 
defined by the device tree.

At the end, using an index here is simply an optional alternative to the 
name, as seen in other framework implementations.

Regards,
Arnaud

> 
> (and yes I know someone here at TI did this alias naming for our
> keystone platforms, but if not for possible backwards compat breaks
> I'd love to remove that one also)
> 
> Andrew
> 
>> 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-by: Peng Fan <peng.fan@nxp.com>
>> ---
>> V3:
>> - fix double space typo
>> - add Peng Fan's Tested-by
>>
>> 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..4a02814c5d04 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);
>> +    /*
>> +     * No alias has been assigned to this remoteproc device. 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);
>> +}
>> +
>>   /**
>>    * rproc_alloc() - allocate a remote processor handle
>>    * @dev: the underlying device
>> @@ -2481,8 +2518,7 @@ 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);
>>       if (rproc->index < 0) {
>>           dev_err(dev, "ida_alloc failed: %d\n", rproc->index);
>>           goto put_device;
>> diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
>> index b4795698d8c2..3feb2456ecc4 100644
>> --- a/include/linux/remoteproc.h
>> +++ b/include/linux/remoteproc.h
>> @@ -503,6 +503,9 @@ enum rproc_features {
>>       RPROC_MAX_FEATURES,
>>   };
>> + /* device tree remoteproc Alias stem */
>> + #define RPROC_ALIAS "rproc"
>> +
>>   /**
>>    * struct rproc - represents a physical remote processor device
>>    * @node: list node of this rproc object
> 

On 2/5/26 11:58 AM, Arnaud POULIQUEN wrote:
> Hello,
> 
> On 2/4/26 15:57, Andrew Davis wrote:
>> On 2/4/26 4:52 AM, 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.
>>>
>>
>> While I will agree it is slightly more complicated in userspace to lookup
>> the device by name string rather than by some static number, there seems to
>> be a good reason for not doing this also.
>>
>> Much like network interfaces where the /dev/eth<x> can change each boot and
>> attempts to make that static from kernel has been turned down: having static
>> indexes doesn't make userspace software any more portable.
>>
>> Say you lock your M33 core to rproc<1> on one SoC, it doesn't mean your next
>> SoC will have the same rproc order, or even have a M33 at all. So you still
>> need your userspace code to lookup and check the name, otherwise you make
>> bad assumptions. Not having static IDs forces software to do the correct
>> thing here.
> 
> That was also my initial approach, but it is difficult to impose on our customers who have legacy applications, especially since they are accustomed to using fixed indexes with other framework ABIs.
> 
>>
>> The only valid reason I can think up is maybe this makes board specific
>> documentation easier. One can say:
>>
>> "On the STM32MP257F-DK, check that the M33 has booted by running
>> `cat /sys/class/remoteproc/remoteproc3/status`"
>>
>> without having to first find the right number by checking each
>> `remoteproc<x>/name`. But wouldn't adding something like a named
>> sysfs dir syslinks work even better?
>>
>> `cat /sys/class/remoteproc/m33@76000000/status`
> 
> The only benefit I can see in checking /sys/class/remoteproc/<name>/status instead of /sys/class/remoteproc/remoteproc<x>/name is to avoid iterating over devices by name. However, in both cases, the application still needs to know the remote processor name, which is platform-dependent and usually defined by the device tree.
> 
> At the end, using an index here is simply an optional alternative to the name, as seen in other framework implementations.
> 

Yes, both name and number based indexing will be platform-dependent, but
they are not purely equivalent. The thing I want to avoid about number based
lookup is in documentation. I see docs already that say something like

> To start the R5F core run this command:
> echo start > /sys/class/remoteproc/remoteproc2/state

And folks (or LLMs being trained on the docs) might assume this is in
any way a portable thing to do. Which we know it is not, the number might
change even between two platforms from the same vendor. Where as if the
instructions said:

> echo start > /sys/class/remoteproc/78000000.r5f/state

It becomes immediately obvious this is valid only for a given platform.

The other thing I want to avoid is the ever-growing alias lists in DT.
Could be done without having to add a list of aliases to every DT. Is
there no other heuristic that we could use to produce an static ordering?

Andrew

> Regards,
> Arnaud
> 
>>
>> (and yes I know someone here at TI did this alias naming for our
>> keystone platforms, but if not for possible backwards compat breaks
>> I'd love to remove that one also)
>>
>> Andrew
>>
>>> 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-by: Peng Fan <peng.fan@nxp.com>
>>> ---
>>> V3:
>>> - fix double space typo
>>> - add Peng Fan's Tested-by
>>>
>>> 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..4a02814c5d04 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);
>>> +    /*
>>> +     * No alias has been assigned to this remoteproc device. 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);
>>> +}
>>> +
>>>   /**
>>>    * rproc_alloc() - allocate a remote processor handle
>>>    * @dev: the underlying device
>>> @@ -2481,8 +2518,7 @@ 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);
>>>       if (rproc->index < 0) {
>>>           dev_err(dev, "ida_alloc failed: %d\n", rproc->index);
>>>           goto put_device;
>>> diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
>>> index b4795698d8c2..3feb2456ecc4 100644
>>> --- a/include/linux/remoteproc.h
>>> +++ b/include/linux/remoteproc.h
>>> @@ -503,6 +503,9 @@ enum rproc_features {
>>>       RPROC_MAX_FEATURES,
>>>   };
>>> + /* device tree remoteproc Alias stem */
>>> + #define RPROC_ALIAS "rproc"
>>> +
>>>   /**
>>>    * struct rproc - represents a physical remote processor device
>>>    * @node: list node of this rproc object
>>
> 

On 2/5/26 21:07, Andrew Davis wrote:
> On 2/5/26 11:58 AM, Arnaud POULIQUEN wrote:
>> Hello,
>>
>> On 2/4/26 15:57, Andrew Davis wrote:
>>> On 2/4/26 4:52 AM, 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.
>>>>
>>>
>>> While I will agree it is slightly more complicated in userspace to 
>>> lookup
>>> the device by name string rather than by some static number, there 
>>> seems to
>>> be a good reason for not doing this also.
>>>
>>> Much like network interfaces where the /dev/eth<x> can change each 
>>> boot and
>>> attempts to make that static from kernel has been turned down: having 
>>> static
>>> indexes doesn't make userspace software any more portable.
>>>
>>> Say you lock your M33 core to rproc<1> on one SoC, it doesn't mean 
>>> your next
>>> SoC will have the same rproc order, or even have a M33 at all. So you 
>>> still
>>> need your userspace code to lookup and check the name, otherwise you 
>>> make
>>> bad assumptions. Not having static IDs forces software to do the correct
>>> thing here.
>>
>> That was also my initial approach, but it is difficult to impose on 
>> our customers who have legacy applications, especially since they are 
>> accustomed to using fixed indexes with other framework ABIs.
>>
>>>
>>> The only valid reason I can think up is maybe this makes board specific
>>> documentation easier. One can say:
>>>
>>> "On the STM32MP257F-DK, check that the M33 has booted by running
>>> `cat /sys/class/remoteproc/remoteproc3/status`"
>>>
>>> without having to first find the right number by checking each
>>> `remoteproc<x>/name`. But wouldn't adding something like a named
>>> sysfs dir syslinks work even better?
>>>
>>> `cat /sys/class/remoteproc/m33@76000000/status`
>>
>> The only benefit I can see in checking /sys/class/remoteproc/<name>/ 
>> status instead of /sys/class/remoteproc/remoteproc<x>/name is to avoid 
>> iterating over devices by name. However, in both cases, the 
>> application still needs to know the remote processor name, which is 
>> platform-dependent and usually defined by the device tree.
>>
>> At the end, using an index here is simply an optional alternative to 
>> the name, as seen in other framework implementations.
>>
> 
> Yes, both name and number based indexing will be platform-dependent, but
> they are not purely equivalent. The thing I want to avoid about number 
> based
> lookup is in documentation. I see docs already that say something like
> 
>> To start the R5F core run this command:
>> echo start > /sys/class/remoteproc/remoteproc2/state
> 
> And folks (or LLMs being trained on the docs) might assume this is in
> any way a portable thing to do. Which we know it is not, the number might
> change even between two platforms from the same vendor. Where as if the
> instructions said:
> 
>> echo start > /sys/class/remoteproc/78000000.r5f/state


For the time being, this approach does not align with other /sys/class/
declarations, which are index-based. You would also need to duplicate the
remoteproc device for legacy support (e.g., 
/sys/class/remoteproc/remoteproc0
and /sys/class/remoteproc/78000000.r5f).

However, if you want to promote this approach, feel free to propose a patch
series. From my perspective, the index mechanism combined with DT aliases
seems like a better compromise.

> 
> It becomes immediately obvious this is valid only for a given platform.
> 
> The other thing I want to avoid is the ever-growing alias lists in DT.

For my understanding, is this only your expectation, or is it a general 
direction recommended by the Linux maintainers?

> Could be done without having to add a list of aliases to every DT. Is
> there no other heuristic that we could use to produce an static ordering?

Other alternatives I can see are:
- use of the reg property: whould break legacy.
- add a new proc node property: would do the same than the
   existing alias.

Regards,
Arnaud

> 
> Andrew
> 
>> Regards,
>> Arnaud
>>
>>>
>>> (and yes I know someone here at TI did this alias naming for our
>>> keystone platforms, but if not for possible backwards compat breaks
>>> I'd love to remove that one also)
>>>
>>> Andrew
>>>
>>>> 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-by: Peng Fan <peng.fan@nxp.com>
>>>> ---
>>>> V3:
>>>> - fix double space typo
>>>> - add Peng Fan's Tested-by
>>>>
>>>> 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..4a02814c5d04 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);
>>>> +    /*
>>>> +     * No alias has been assigned to this remoteproc device. 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);
>>>> +}
>>>> +
>>>>   /**
>>>>    * rproc_alloc() - allocate a remote processor handle
>>>>    * @dev: the underlying device
>>>> @@ -2481,8 +2518,7 @@ 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);
>>>>       if (rproc->index < 0) {
>>>>           dev_err(dev, "ida_alloc failed: %d\n", rproc->index);
>>>>           goto put_device;
>>>> diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
>>>> index b4795698d8c2..3feb2456ecc4 100644
>>>> --- a/include/linux/remoteproc.h
>>>> +++ b/include/linux/remoteproc.h
>>>> @@ -503,6 +503,9 @@ enum rproc_features {
>>>>       RPROC_MAX_FEATURES,
>>>>   };
>>>> + /* device tree remoteproc Alias stem */
>>>> + #define RPROC_ALIAS "rproc"
>>>> +
>>>>   /**
>>>>    * struct rproc - represents a physical remote processor device
>>>>    * @node: list node of this rproc object
>>>
>>
> 

On Mon, Feb 09, 2026 at 10:51:07AM +0100, Arnaud POULIQUEN wrote:
> On 2/5/26 21:07, Andrew Davis wrote:
> > On 2/5/26 11:58 AM, Arnaud POULIQUEN wrote:
> > > On 2/4/26 15:57, Andrew Davis wrote:
> > > > On 2/4/26 4:52 AM, Arnaud Pouliquen wrote:
[..]
> > 
> > It becomes immediately obvious this is valid only for a given platform.
> > 
> > The other thing I want to avoid is the ever-growing alias lists in DT.
> 
> For my understanding, is this only your expectation, or is it a general
> direction recommended by the Linux maintainers?
> 

If I remember correctly I did stand by the idea of using aliases to get
stable numbering in /sys/class/remoteproc when we spoke about it several
years ago (6-7?). But remoteprocs are coming and going, and any
information we would have encoded in those numbers would have been
confusing.

A big problem is that your numbering scheme will not be consistent over
time and as such prevent your customers from reusing the same userspace
between different platforms.

Another one is for the developer, who need to remember that on platform
A the R5F is id 2, but on platform B it's id 3 - when they sit and write
their echo commands.

Replying on properly maintained rproc->name handles both of these cases
for you.

> > Could be done without having to add a list of aliases to every DT. Is
> > there no other heuristic that we could use to produce an static ordering?
> 
> Other alternatives I can see are:
> - use of the reg property: whould break legacy.

That obviously wouldn't work if you remoteproc is a mmio device.

> - add a new proc node property: would do the same than the
>   existing alias.

If we decide that a global id-scheme is the right way to go, then alias
is the mechanism to express that. There's no reason to hack around it...

But I don't think it is the right solution. How about providing our
users a reference snippet, licensed as public domain, that just resolves
a remoteproc by the name property?

Regards,
Bjorn

hello,

On 2/9/26 16:23, Bjorn Andersson wrote:
> On Mon, Feb 09, 2026 at 10:51:07AM +0100, Arnaud POULIQUEN wrote:
>> On 2/5/26 21:07, Andrew Davis wrote:
>>> On 2/5/26 11:58 AM, Arnaud POULIQUEN wrote:
>>>> On 2/4/26 15:57, Andrew Davis wrote:
>>>>> On 2/4/26 4:52 AM, Arnaud Pouliquen wrote:
> [..]
>>>
>>> It becomes immediately obvious this is valid only for a given platform.
>>>
>>> The other thing I want to avoid is the ever-growing alias lists in DT.
>>
>> For my understanding, is this only your expectation, or is it a general
>> direction recommended by the Linux maintainers?
>>
> 
> If I remember correctly I did stand by the idea of using aliases to get
> stable numbering in /sys/class/remoteproc when we spoke about it several
> years ago (6-7?). But remoteprocs are coming and going, and any
> information we would have encoded in those numbers would have been
> confusing.
> 
> A big problem is that your numbering scheme will not be consistent over
> time and as such prevent your customers from reusing the same userspace
> between different platforms.

Precisely by setting the alias in the DT on their board, they should be able
to reuse legacy application. The index provides an abstraction layer.

> 
> Another one is for the developer, who need to remember that on platform
> A the R5F is id 2, but on platform B it's id 3 - when they sit and write
> their echo commands.

They are already facing this issue because the remoteproc device name 
set in stm32_rproc_probe() is derived from the device tree (DT) node 
name. This may also be true for other platforms. Consequently, the 
application must know the name defined in the DT. If the DT name 
changes, userspace must be updated accordingly.

Alternatively, we would probably have to update the device name by 
handling it within the driver to break the dependency between the 
application and the DT. But it will also impact legacy applications.

> 
> Replying on properly maintained rproc->name handles both of these cases
> for you.
> 
>>> Could be done without having to add a list of aliases to every DT. Is
>>> there no other heuristic that we could use to produce an static ordering?
>>
>> Other alternatives I can see are:
>> - use of the reg property: whould break legacy.
> 
> That obviously wouldn't work if you remoteproc is a mmio device.
> 
>> - add a new proc node property: would do the same than the
>>    existing alias.
> 
> If we decide that a global id-scheme is the right way to go, then alias
> is the mechanism to express that. There's no reason to hack around it...

Should we consider this as a solution or just an optional alternative? 
I’m quite confused as to why we cannot propose this mechanism and allow 
userspace to decide which approach to use.

> 
> But I don't think it is the right solution. How about providing our
> users a reference snippet, licensed as public domain, that just resolves
> a remoteproc by the name property?


If this series is not accepted, we plan to implement it downstream to 
facilitate legacy application porting between our STM32MP1 and STM32MP2 
series, with ST documentation to explain both alternatives.

Thanks and regards,
Arnaud

> 
> Regards,
> Bjorn