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

[Shenwei Wang]

> -----Original Message-----
> From: Bjorn Andersson <andersson at kernel.org>
> Sent: Wednesday, February 25, 2026 9:53 AM
> To: Shenwei Wang <shenwei.wang at nxp.com>
> Cc: Andrew Lunn <andrew at lunn.ch>; Mathieu Poirier
> <mathieu.poirier at linaro.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
> 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...
> 

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

Thanks,
Shenwei

> 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