On Mon, Feb 23, 2026 at 03:24:43PM +0100, Arnaud POULIQUEN wrote:

On 2/22/26 15:48, Linus Walleij wrote:

quoted

On Fri, Feb 20, 2026 at 7:57 PM Shenwei Wang [off-list ref] wrote:

[..]

quoted

Is it generic? If it is not, let's call it "NXP rpmsg GPIO driver" and rename
files etc accordingly. Maybe it can share code with the actual generic
RPMSG driver once that arrives, that is more of a library question.

I would like to (re)express my concerns regarding the creation of an
NXP-specific driver. To clarify my concerns, ST, like probably some other
SoC vendors, has rpmsg-gpio and rpmsg-i2c drivers in downstream with plans
to upstream them.

If we proceed in this direction:

-Any vendor wishing to upstream an rpmsg-gpio driver might submit their own
platform-specific version.

- If NXP upstreams other rpmsg drivers, these will likely remain NXP-centric
to maintain compatibility with their legacy firmware and the nxp-rpmsg-gpio
driver, leading to platform-specific versions in several frameworks.

- The implementation will impact not only the Linux side but also the remote
side. Indeed, some operating systems like Zephyr or NuttX implement the
rpmsg device side (Zephyr already implements the rpmsg-tty)

Maintaining a generic approach for RPMsg, similar to what is done for
Virtio, seems to me a more reliable solution, even though it may induce some
downstream costs (ST would also need to break compatibility with legacy ST
remote proc firmware).

Could the virtio-based mechanism be used directly (without rpmsg)?


If not, it would be good to derive a generic rpmsg-gpio protocol from
the virtio protocol, and land implementations of this in e.g. Linux and
Zephyr to establish that option.

Regards,
Bjorn

In the end, I am just trying to influence the direction for RPMsg, but based
on the discussions in this thread, it seems others share similar
expectations, which should probably be taken into account as well.

Thanks and Regards,
Arnaud


I just want to

quoted

Yours,
Linus Walleij