Message-ID: <05d713dd-ec4b-4ec6-a1b7-4e6453133d8b@foss.st.com>
Date: Mon, 9 Feb 2026 19:28:00 +0100
From: Arnaud POULIQUEN <arnaud.pouliquen@...s.st.com>
To: Bjorn Andersson <andersson@...nel.org>
CC: Andrew Davis <afd@...com>, Mathieu Poirier <mathieu.poirier@...aro.org>,
	<linux-remoteproc@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<linux-stm32@...md-mailman.stormreply.com>
Subject: Re: [PATCH v3 1/2] remoteproc: core: support fixed device index from
 DT aliases

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

Powered by blists - more mailing lists