[PATCH v8 3/4] gpio: rpmsg: add generic rpmsg GPIO driver

[Bjorn Andersson]

On Tue, Feb 24, 2026 at 10:43:06PM +0000, Shenwei Wang wrote:
> 
> 
> > -----Original Message-----
> > From: Andrew Lunn <andrew at lunn.ch>
> > Sent: Tuesday, February 24, 2026 4:15 PM
> > To: Shenwei Wang <shenwei.wang at nxp.com>
> > Cc: Mathieu Poirier <mathieu.poirier at linaro.org>; Bjorn Andersson
> > <andersson at kernel.org>; Arnaud POULIQUEN
> > <arnaud.pouliquen at foss.st.com>; Linus Walleij <linusw at kernel.org>; Bartosz
> > Golaszewski <brgl at kernel.org>; Jonathan Corbet <corbet at lwn.net>; Rob Herring
> > <robh at kernel.org>; Krzysztof Kozlowski <krzk+dt at kernel.org>; Conor Dooley
> > <conor+dt at kernel.org>; Frank Li <frank.li at nxp.com>; Sascha Hauer
> > <s.hauer at pengutronix.de>; Shuah Khan <skhan at linuxfoundation.org>; linux-
> > gpio at vger.kernel.org; linux-doc at vger.kernel.org; linux-kernel at vger.kernel.org;
> > Pengutronix Kernel Team <kernel at pengutronix.de>; Fabio Estevam
> > <festevam at gmail.com>; Peng Fan <peng.fan at nxp.com>;
> > devicetree at vger.kernel.org; linux-remoteproc at vger.kernel.org;
> > imx at lists.linux.dev; linux-arm-kernel at lists.infradead.org; dl-linux-imx <linux-
> > imx at nxp.com>; Bartosz Golaszewski <brgl at bgdev.pl>
> > Subject: [EXT] Re: [PATCH v8 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
> > > 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
> 
> > 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