On 6/19/25 10:53 AM, Mathieu Poirier wrote:

Good morning,

On Wed, 18 Jun 2025 at 10:44, Tanmay Shah tanmay.shah@amd.com wrote:

...

Hello all,

I found out that there is discrepancy between remoteproc state definition in kernel and open-amp library:

Linux kernel side definition:

https://github.com/torvalds/linux/blob/52da431bf03b5506203bca27fe14a97895c80...

enum rproc_state { RPROC_OFFLINE = 0, RPROC_SUSPENDED = 1, RPROC_RUNNING = 2, RPROC_CRASHED = 3, RPROC_DELETED = 4, RPROC_ATTACHED = 5, RPROC_DETACHED = 6, RPROC_LAST = 7, };

open-amp library side definition:

https://github.com/OpenAMP/open-amp/blob/391671ba24840833d882c1a75c5d7307703...

/**

• @brief Remote processor states

*/ enum remoteproc_state { /** Remote is offline */ RPROC_OFFLINE = 0, /** Remote is configured */ RPROC_CONFIGURED = 1, /** Remote is ready to start */ RPROC_READY = 2, /** Remote is up and running */ RPROC_RUNNING = 3, /** Remote is suspended */ RPROC_SUSPENDED = 4, /** Remote is has error; need to recover */ RPROC_ERROR = 5, /** Remote is stopped */ RPROC_STOPPED = 6, /** Just keep this one at the end */ RPROC_LAST = 7, };

IIUC, both side state definition should match, so that if remote needs to report crash error, it can use same name and mapped int value in the code. Please let me know if I am missing something in this understanding.

Should we fix this?

The kernel's remoteproc subsystem and openAMP library are two independent projects. OpenAMP does its own governance but I personally don't see a reason to harmonize the value of their internal states.

Thanks, Mathieu

Thanks Mathieu for your response. Yes we are reaching the same conclusion.

...

If so, I believe it should be library side.

I am looking for suggestion to fix this without breaking backward compatibility:

Approach 1: deprecate library side remoteproc_state definition.

deprecate current enum (with __deprecated attribute or add comment) and introduce new one with same definition as in linux kernel. Then after 2 year (as per code of conduct policy) we can remove remoteproc_state.

Approach 2: Platform driver uses library side remoteproc state definition.

If we don't want to fix this, then another approach is, platform driver in linux kernel should have library-side remoteproc state definition and convert interprete it to kernel side remoteproc definition.

With this second approach we don't have to deprecate anything, but platform drivers are responsible to maintain different remoteproc_state definition. (Might create confusion).

I am open to any other suggestion regarding this.

Thanks, Tanmay