linux-kernel - Re: [PATCH] remoteproc: core: Honor device tree /alias entries when assigning IDs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 22 Aug 2023 15:12:05 -0500
From:   Nishanth Menon <nm@...com>
To:     Mathieu Poirier <mathieu.poirier@...aro.org>
CC:     Bjorn Andersson <andersson@...nel.org>,
        <linux-kernel@...r.kernel.org>, <linux-remoteproc@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        Robert Nelson <robertcnelson@...il.com>,
        Kevin Cahalan <kevinacahalan@...il.com>
Subject: Re: [PATCH] remoteproc: core: Honor device tree /alias entries when
 assigning IDs

On 13:25-20230822, Mathieu Poirier wrote:
> Hi Nishanth,
> 
> On Mon, Aug 07, 2023 at 09:02:47AM -0500, Nishanth Menon wrote:
> > On many platforms, such as Beaglebone-AI64 with many remote
> > processors, firmware configurations provided by the distributions can
> > vary substantially depending on the distribution build's functionality
> > and the specific remote cores enabled in that variant. Ensuring
> > consistent udev rules mapping remoteproc nodes to constant remote
> > proc device indices across distributions (yocto, ubuntu, debian and
> > it's variants, ...) on a board basis can be challenging due to the
> > various functions of these distributions. Varied device node paths
> > create challenges for applications that operate on remote processors,
> > especially in minimal embedded systems(initrd like) that may not
> > have udev-like capabilities and rely on a more straightforward bare
> > filesystem. This challenge is similar to that faced by I2C, RTC or the
> > GPIO subsystems.
> >
> 
> I'm puzzled by this patch.  I can see how using an alias can help in boards with
> various HW configuration.  That said, and as written above, FW files for remote
> processors can vary based on the build's functionality.  As such "remoteproc3"
> will reference the same HW device on all distributions but the functionality
> enacted by the FW may be different.  As such I don't see how an alias can help
> here.  Can you provide a concrete example that highlights the benefits?

Correct - *if* remoteproc3 is the constant node reference.

To take a trivial example: We ran into this issue with:
https://github.com/kaofishy/bbai64_cortex-r5_example/blob/main/Makefile#L28

remoteproc18 apparently changed numbering in a different build.

If remoteproc18 remained the same between different distro builds that
would have probably kept the userspace constant. but it does'nt. it
dependent purely on probe order, which does'nt let userspace remain
consistent.

Same reason and motivation to do the following:
https://git.beagleboard.org/beagleboard/repos-arm64/-/blob/main/bb-customizations/suite/bookworm/debian/86-remoteproc-noroot.rules
in one technique to do it - but that only works if all the distros
follow the same udev rules - and there is no reasonable way to enforce
that across distributions.

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D