-----Original Message-----
From: Bjorn Andersson <andersson@kernel.org>
Sent: Monday, February 23, 2026 8:43 AM
To: Arnaud POULIQUEN <arnaud.pouliquen@foss.st.com>
Cc: Linus Walleij <linusw@kernel.org>; Shenwei Wang
[off-list ref]; Andrew Lunn [off-list ref]; Bartosz
Golaszewski [off-list ref]; Jonathan Corbet [off-list ref]; Rob Herring
[off-list ref]; Krzysztof Kozlowski [off-list ref]; Conor Dooley
[off-list ref]; Mathieu Poirier [off-list ref]; Frank Li
[off-list ref]; Sascha Hauer [off-list ref]; Shuah Khan
[off-list ref]; linux-gpio@vger.kernel.org; linux-
doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix Kernel Team
[off-list ref]; Fabio Estevam [off-list ref]; Peng Fan
[off-list ref]; devicetree@vger.kernel.org; linux-
remoteproc@vger.kernel.org; imx@lists.linux.dev; linux-arm-
kernel@lists.infradead.org; dl-linux-imx [off-list ref]; Bartosz
Golaszewski [off-list ref]
Subject: [EXT] Re: [PATCH v8 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
On Mon, Feb 23, 2026 at 03:24:43PM +0100, Arnaud POULIQUEN wrote:

quoted

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

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.

quoted

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.

quoted

- 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)?

Technically, yes—it's possible to use the virtio mechanism directly without rpmsg.
It’s a bit like talking straight to the IP layer without involving TCP or UDP: doable, but 
at a lower‑level approach.

As for the idea of gpio‑virtio, which could be an optional solution that certain customers 
might prefer. I recall hearing this idea from Mathieu originally, though I’m not sure whether 
he plans to implement it.

As the chip vendor, NXP’s role is to provide all possible options and let customers choose 
the approach that best fits their needs; we don’t make that decision for them.

Thanks,
Shenwei

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

quoted

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