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

[Bjorn Andersson]

On Wed, Feb 25, 2026 at 05:54:00PM +0000, Shenwei Wang wrote:
> 
> 
> > -----Original Message-----
> > From: Bjorn Andersson <andersson@xxxxxxxxxx>
> > Sent: Wednesday, February 25, 2026 9:53 AM
> > To: Shenwei Wang <shenwei.wang@xxxxxxx>
> > Cc: Andrew Lunn <andrew@xxxxxxx>; Mathieu Poirier
> > <mathieu.poirier@xxxxxxxxxx>; Arnaud POULIQUEN
> > <arnaud.pouliquen@xxxxxxxxxxx>; Linus Walleij <linusw@xxxxxxxxxx>; Bartosz
> > Golaszewski <brgl@xxxxxxxxxx>; Jonathan Corbet <corbet@xxxxxxx>; Rob Herring
> > <robh@xxxxxxxxxx>; Krzysztof Kozlowski <krzk+dt@xxxxxxxxxx>; Conor Dooley
> > <conor+dt@xxxxxxxxxx>; Frank Li <frank.li@xxxxxxx>; Sascha Hauer
> > <s.hauer@xxxxxxxxxxxxxx>; Shuah Khan <skhan@xxxxxxxxxxxxxxxxxxx>; linux-
> > gpio@xxxxxxxxxxxxxxx; linux-doc@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
> > Pengutronix Kernel Team <kernel@xxxxxxxxxxxxxx>; Fabio Estevam
> > <festevam@xxxxxxxxx>; Peng Fan <peng.fan@xxxxxxx>;
> > devicetree@xxxxxxxxxxxxxxx; linux-remoteproc@xxxxxxxxxxxxxxx;
> > imx@xxxxxxxxxxxxxxx; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; dl-linux-imx <linux-
> > imx@xxxxxxx>; Bartosz Golaszewski <brgl@xxxxxxxx>
> > 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@xxxxxxx>
> > > > Sent: Tuesday, February 24, 2026 4:15 PM
> > > > To: Shenwei Wang <shenwei.wang@xxxxxxx>
> > > > Cc: Mathieu Poirier <mathieu.poirier@xxxxxxxxxx>; Bjorn Andersson
> > > > <andersson@xxxxxxxxxx>; Arnaud POULIQUEN
> > > > <arnaud.pouliquen@xxxxxxxxxxx>; Linus Walleij <linusw@xxxxxxxxxx>;
> > > > Bartosz Golaszewski <brgl@xxxxxxxxxx>; Jonathan Corbet
> > > > <corbet@xxxxxxx>; Rob Herring <robh@xxxxxxxxxx>; Krzysztof Kozlowski
> > > > <krzk+dt@xxxxxxxxxx>; Conor Dooley <conor+dt@xxxxxxxxxx>; Frank Li
> > > > <frank.li@xxxxxxx>; Sascha Hauer <s.hauer@xxxxxxxxxxxxxx>; Shuah
> > > > Khan <skhan@xxxxxxxxxxxxxxxxxxx>; linux- gpio@xxxxxxxxxxxxxxx;
> > > > linux-doc@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Pengutronix
> > > > Kernel Team <kernel@xxxxxxxxxxxxxx>; Fabio Estevam
> > > > <festevam@xxxxxxxxx>; Peng Fan <peng.fan@xxxxxxx>;
> > > > devicetree@xxxxxxxxxxxxxxx; linux-remoteproc@xxxxxxxxxxxxxxx;
> > > > imx@xxxxxxxxxxxxxxx; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx;
> > > > dl-linux-imx <linux- imx@xxxxxxx>; Bartosz Golaszewski
> > > > <brgl@xxxxxxxx>
> > > > 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.

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