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
