-----Original Message-----
From: Bjorn Andersson <andersson@kernel.org>
Sent: Wednesday, February 25, 2026 1:44 PM
To: Shenwei Wang <shenwei.wang@nxp.com>
Cc: Andrew Lunn <andrew@lunn.ch>; Mathieu Poirier
[off-list ref]; Arnaud POULIQUEN
[off-list ref]; Linus Walleij [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 <linux-
imx@nxp.com>; Bartosz Golaszewski [off-list ref]
Subject: [EXT] Re: [PATCH v8 3/4] gpio: rpmsg: add generic rpmsg GPIO driver

Caution: This is an external email. Please take care when clicking links or opening
attachments. When in doubt, report the message using the 'Report this email'
button


On Wed, Feb 25, 2026 at 05:54:00PM +0000, Shenwei Wang wrote:

quoted

quoted

-----Original Message-----
From: Bjorn Andersson <andersson@kernel.org>
Sent: Wednesday, February 25, 2026 9:53 AM
To: Shenwei Wang <shenwei.wang@nxp.com>
Cc: Andrew Lunn <andrew@lunn.ch>; Mathieu Poirier
[off-list ref]; Arnaud POULIQUEN
[off-list ref]; Linus Walleij [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 <linux- imx@nxp.com>; Bartosz Golaszewski
[off-list ref]
Subject: [EXT] Re: [PATCH v8 3/4] gpio: rpmsg: add generic rpmsg
GPIO driver On Tue, Feb 24, 2026 at 10:43:06PM +0000, Shenwei Wang

wrote:

quoted

quoted

quoted

quoted

-----Original Message-----
From: Andrew Lunn <andrew@lunn.ch>
Sent: Tuesday, February 24, 2026 4:15 PM
To: Shenwei Wang <shenwei.wang@nxp.com>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>; Bjorn
Andersson [off-list ref]; Arnaud POULIQUEN
[off-list ref]; Linus Walleij
[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 <linux- imx@nxp.com>; Bartosz Golaszewski
[off-list ref]
Subject: [EXT] Re: [PATCH v8 3/4] gpio: rpmsg: add generic rpmsg
GPIO driver

quoted

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

We have already seen the virtio commands are pretty much
identical to what i suggested.

You could just replace virtqueue_add_sgs() with rpmsg_sendto()
and reimplement
virtio_gpio_request_vq() to be the callback registered with

rpmsg_create_ept().

quoted

quoted

The rest of basic GPIO handling should not need any changes at all.

Creating endpoints and calling rpmsg_sendto() is only a small part
of the picture. You also need to manage the service announcement
from the remote side and handle asynchronous notification
messages. That entire flow is already implemented in the existing

virtio_rpmsg_bus driver.

quoted

quoted

quoted

Re‑implementing those pieces just to mimic gpio‑virtio over RPMSG
would

essentially mean reinventing the wheel without any real benefit.

quoted

I can absolutely see a benefit to this, there are multiple different
rpmsg backends supported in Linux, so a gpio-rpmsg driver could be used by

any one of them.

quoted

quoted

I don't see this to be a case of "reinventing the wheel". Instead we
copy what looks to be a very functional wheel and make it fit rpmsg.
This will result in some "duplication", but rpmsg already provide
the life cycle management and has a clean send/callback interface,
so there shouldn't be any inventing...

Interesting — could you walk me through how you’d structure the driver
with the new proposal? I’d like to see how you would layer it conceptually.

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

What I'm suggesting is the following:

GPIOs -> RPMSG -> VIRTIO == VIRTIO -> RPMSG -> GPIO-RPMSG
       ^                                    ^
       \-----+------------------------------/
             |
             |
With this interface on being directly derived from the existing protocol (and likely
the implementation as well) using gpio-virtio.

You can have multiple "GPIOs" (presumably a "bank" each) instances and that
will be reflected in having multiple "GPIO-RPMSG" instances.

I haven't made any attempts at implementing this, but it looks very similar to
gpio-virtio in concept and it looks very similar to the exiting RPMSG tty in the
sense of being a generic implementation.

To reach something functional on the Linux side it seems to be a matter of taking
the gpio-virtio driver, register a rpmsg_driver instead, change _virtio_gpio_req()
to use rpmsg_send(), and perform the actions of virtio_gpio_event_vq() in the
rpmsg_driver callback function.

Thanks for the explanation. If I’m understanding correctly, what you’re suggesting is 
essentially a driver that merges the roles of a virtio_driver and an rpmsg_driver into a 
single source file. There may be opportunities for a few function reuse, but overall it 
would still result in a fairly distinct codebase.

Thanks,
Shenwei

Regards,
Bjorn

quoted

Thanks,
Shenwei

quoted

Similarly, I'm guessing that there's a firmware-side implementation
of virtio-gpio in Zephyr, it should be straightforward to transplant this to the

rpmsg interface.

quoted

quoted

Regards,
Bjorn

quoted

Thanks,
Shenwei

quoted

Interrupt support does however need some changes. The
virtio_gpio_request_vq() replacement would need to see if the
received message indicates an interrupt and call the equivalent
of virtio_gpio_event_vq(), since rpmsg does not have a separate
mechanism to

deliver interrupts, unlike rpmsg.

quoted

quoted

At a guess, 90% of the code would stay the same?

   Andrew