-----Original Message-----
From: Mathieu Poirier <mathieu.poirier@linaro.org>
Sent: Tuesday, February 24, 2026 2:41 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

quoted

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

quoted

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

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.

quoted

We clearly do not understand each other.

The current RPMSG solution:

     On Remoteprc                      On Linux
GPIOs -> RPMSG -> VIRTIO == VIRTIO -> RPMSG -> GPIO-RPMSG drivers

The VIRTIO solution:

     On Remoteprc                     On Linux
          GPIO -> VIRTIO == VIRTIO -> GPIO-VIRTIO driver

Your proposal:
     On Remoteprc                     On Linux
GPIOs -> RPMSG -> VIRTIO == VIRTIO -> ???

This is your comments:  "For those cases a generic rpmsg-gpio protocol should 
be derived from gpio-virtio"

Please explain how you would design your generic rpmsg-gpio driver which is derived
From gpio-virtio?

Thanks,
Shenwei

quoted

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

quoted

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.

quoted

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.

quoted

quoted

quoted

quoted

quoted

Thanks and Regards,
Arnaud


I just want to

quoted

Yours,
Linus Walleij