On Tue, 24 Feb 2026 at 13:17, Shenwei Wang [off-list ref] wrote:

quoted

-----Original Message-----
From: Mathieu Poirier <mathieu.poirier@linaro.org>
Sent: Tuesday, February 24, 2026 12:10 PM
To: Shenwei Wang <shenwei.wang@nxp.com>
Cc: Bjorn Andersson <andersson@kernel.org>; Arnaud POULIQUEN
[off-list ref]; Linus Walleij [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]; 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 Tue, 24 Feb 2026 at 08:56, Shenwei Wang [off-list ref] wrote:

quoted

quoted

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

quoted

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.

quoted

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 Daniel pointed out, gpio-virtio is already available and already includes a
protocol that is generic - no need to redefine a new one as this set is trying to.

As mentioned in a previous email, I understand some implementations will have
restricted memory and need to use RPMSG.  For those cases a generic rpmsg-gpio

I think this highlights why some customers prefer RPMSG over using virtio directly. Limited
system resources and development efficiency are the two main reasons that make RPMSG
a better fit for certain environments.

quoted

protocol should be derived from gpio-virtio that would only deal with breaking
down the standard gpio-virtio protocol into something digestible by RPMSG.  That
was Bjorn's point in an earlier message.  This will allow to use the same interface
and be flexible in how we want to talk to the transport medium, i.e pure gpio-
virtio or rpmsg-gpio.

Once the remoteproc chooses to expose devices through an RPMSG‑based protocol,
deriving another driver from gpio‑virtio doesn’t really make sense. That would essentially
mean re‑implementing parts of RPMSG yourself instead of using existing one.

We clearly do not understand each other.

quoted

Fortunately RPMSG already uses channels to differentiate between traffic, no
need to multiplex everything on the same channel.  That too needs to go.

quoted

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.

As kernel maintainers, our role is to advise on designs that are generic, simple,
maintainable and stand the test of time.

These adjectives only make sense within the context of a specific use case. Different
 systems have different constraints, and people choose a particular solution for valid
reasons based on their requirements.

You can choose whatever solution you want, that is entirely up to you.
Maintainers can also choose to reject that solution for mainline
Linux, which is exactly what we are doing.

Please respect their efforts.

Thanks,
Shenwei

quoted

quoted

Thanks,
Shenwei

quoted

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