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] [day] [month] [year] [list]

Message-ID: <ZOY0W+0YdYRk2v/E@p14s>
Date:   Wed, 23 Aug 2023 10:31:23 -0600
From:   Mathieu Poirier <mathieu.poirier@...aro.org>
To:     Nishanth Menon <nm@...com>
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 Wed, Aug 23, 2023 at 10:51:33AM -0500, Nishanth Menon wrote:
> On 09:23-20230823, Mathieu Poirier wrote:
> > On Tue, Aug 22, 2023 at 03:12:05PM -0500, Nishanth Menon wrote:
> > > 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.
> > > 
> > 
> > We are going around in circles.  In the above link using an alias will
> > guarantee that "remoteproc18" is available but won't guarantee the
> > functionality enacted by the FW loaded in that remote processor, which is distro
> > dependent.
> 
> Apologies, but I am trying to comprehend the relationship and probably
> am failing to see the linkage. Let me try:
> 
> If I understand you correctly, you are concerned that distros do not
> have a mechanism to provide consistent firmware to the correct remote
> proc for a specific functionality..
>

The point is that aliases will guarantee a naming convention for remote
processors but won't guarantee their functionality.  Sure, we can add aliases
but it won't solve all your problems.

> if so, distro loads / provides the requisite firmware. How
> the package distribution scheme works to distribute the firmware
> and versioning provided varies - One typical pattern has been to use
> linux-firmware repo[1] (at least in other domains - say GPU, wlink or
> the likes) and provide package distribution. The other pattern could
> be build and deploy based on tag (this would be no different from any
> other package deployment).
> 
> On the other hand, If we are looking at the fact that there can be
> different types of firmware that could be loaded to a remoteproc
> providing different functionality - that is correct, and at least in
> case of TI processors very valid

That is exactly what I am referring to.

>- something like openAMP endpoint
> solutions probably help?

I am not familiar with openAmP endpoints but certainly willing to consider it as
an option.

> 
> Let me know if I am off-track here..
> 

You are on track.

> [1] https://git.ti.com/cgit/processor-firmware/ti-linux-firmware/tree/ti-ipc?h=ti-linux-firmware
> -- 
> Regards,
> Nishanth Menon
> Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D