Re: [PATCH 1/5] remoteproc: Move resource table data structure to its own header

[Mukesh Ojha]

On Mon, May 25, 2026 at 09:53:57AM -0600, Mathieu Poirier wrote:
> On Wed, May 06, 2026 at 10:31:03AM +0530, Mukesh Ojha wrote:
> > The resource table data structure has traditionally been associated with
> > the remoteproc framework, where the resource table is included as a
> > section within the remote processor firmware binary. However, it is also
> > possible to obtain the resource table through other means—such as from a
> > reserved memory region populated by the boot firmware, statically
> > maintained driver data, or via a secure SMC call—when it is not embedded
> > in the firmware.
> > 
> > There are multiple Qualcomm remote processors (e.g., Venus, Iris, GPU,
> > etc.) in the upstream kernel that do not use the remoteproc framework to
> > manage their lifecycle for various reasons.
> > 
> > When Linux is running at EL2, similar to the Qualcomm PAS driver
> > (qcom_q6v5_pas.c), client drivers for subsystems like video and GPU may
> > also want to use the resource table SMC call to retrieve and map
> > resources before they are used by the remote processor.
> > 
> > In such cases, the resource table data structure is no longer tightly
> > coupled with the remoteproc headers. Client drivers that do not use the
> > remoteproc framework should still be able to parse the resource table
> > obtained through alternative means. Therefore, there is a need to
> > decouple the resource table definitions from the remoteproc headers.
> > 
> > Signed-off-by: Mukesh Ojha <mukesh.ojha@xxxxxxxxxxxxxxxx>
> > ---
> >  include/linux/remoteproc.h | 269 +-------------------------------
> >  include/linux/rsc_table.h  | 306 +++++++++++++++++++++++++++++++++++++
> >  2 files changed, 307 insertions(+), 268 deletions(-)
> >  create mode 100644 include/linux/rsc_table.h
> >
> 
> This patch is giving me a checkpatch.pl warning, related to a missing SPDX
> header.  With that addressed:
> 
> Reviewed-by: Mathieu Poirier <mathieu.poirier@xxxxxxxxxx>
>  

Sure, will take care of it.

-Mukesh