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

Wed Feb 25 13:02:18 PST 2026

On Wed, Feb 25, 2026 at 08:31:33PM +0000, Shenwei Wang wrote:
> 
> 
> > -----Original Message-----
> > From: Bjorn Andersson <andersson at kernel.org>
> > Sent: Wednesday, February 25, 2026 1:44 PM
> > 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
> > 
> > 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:
> > >
> > >
> > > > -----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 -> ???
> > 
> > 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.
> 

Most of the non-boilerplate code in gpio-virtio would be impacted by
differences between rpmsg and virtio. So combining the two
implementations in a single source file would add complexity to an
otherwise straightforward driver, only with trivial parts reused.

My expectation is that it will be better to just have two separate
drivers - but reuse all the design-work done in the gpio-virtio.

Regards,
Bjorn

> Thanks,
> Shenwei
> 
> > Regards,
> > Bjorn
> > 
> > >
> > > 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