On Tue, Feb 24, 2026 at 10:43:06PM +0000, Shenwei Wang wrote:

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().
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. Re‑implementing those pieces just to mimic gpio‑virtio over RPMSG would essentially 
mean reinventing the wheel without any real benefit.

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.

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

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.

Regards,
Bjorn

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.

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

   Andrew