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
