> -----Original Message----- > From: Bjorn Andersson <[email protected]> > Sent: Wednesday, February 25, 2026 1:44 PM > To: Shenwei Wang <[email protected]> > Cc: Andrew Lunn <[email protected]>; Mathieu Poirier > <[email protected]>; Arnaud POULIQUEN > <[email protected]>; Linus Walleij <[email protected]>; Bartosz > Golaszewski <[email protected]>; Jonathan Corbet <[email protected]>; Rob Herring > <[email protected]>; Krzysztof Kozlowski <[email protected]>; Conor Dooley > <[email protected]>; Frank Li <[email protected]>; Sascha Hauer > <[email protected]>; Shuah Khan <[email protected]>; linux- > [email protected]; [email protected]; [email protected]; > Pengutronix Kernel Team <[email protected]>; Fabio Estevam > <[email protected]>; Peng Fan <[email protected]>; > [email protected]; [email protected]; > [email protected]; [email protected]; dl-linux-imx > <linux- > [email protected]>; Bartosz Golaszewski <[email protected]> > 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 <[email protected]> > > > Sent: Wednesday, February 25, 2026 9:53 AM > > > To: Shenwei Wang <[email protected]> > > > Cc: Andrew Lunn <[email protected]>; Mathieu Poirier > > > <[email protected]>; Arnaud POULIQUEN > > > <[email protected]>; Linus Walleij <[email protected]>; > > > Bartosz Golaszewski <[email protected]>; Jonathan Corbet > > > <[email protected]>; Rob Herring <[email protected]>; Krzysztof Kozlowski > > > <[email protected]>; Conor Dooley <[email protected]>; Frank Li > > > <[email protected]>; Sascha Hauer <[email protected]>; Shuah > > > Khan <[email protected]>; linux- [email protected]; > > > [email protected]; [email protected]; Pengutronix > > > Kernel Team <[email protected]>; Fabio Estevam > > > <[email protected]>; Peng Fan <[email protected]>; > > > [email protected]; [email protected]; > > > [email protected]; [email protected]; > > > dl-linux-imx <linux- [email protected]>; Bartosz Golaszewski > > > <[email protected]> > > > 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 <[email protected]> > > > > > Sent: Tuesday, February 24, 2026 4:15 PM > > > > > To: Shenwei Wang <[email protected]> > > > > > Cc: Mathieu Poirier <[email protected]>; Bjorn > > > > > Andersson <[email protected]>; Arnaud POULIQUEN > > > > > <[email protected]>; Linus Walleij > > > > > <[email protected]>; Bartosz Golaszewski <[email protected]>; > > > > > Jonathan Corbet <[email protected]>; Rob Herring <[email protected]>; > > > > > Krzysztof Kozlowski <[email protected]>; Conor Dooley > > > > > <[email protected]>; Frank Li <[email protected]>; Sascha Hauer > > > > > <[email protected]>; Shuah Khan > > > > > <[email protected]>; linux- [email protected]; > > > > > [email protected]; [email protected]; > > > > > Pengutronix Kernel Team <[email protected]>; Fabio Estevam > > > > > <[email protected]>; Peng Fan <[email protected]>; > > > > > [email protected]; [email protected]; > > > > > [email protected]; [email protected]; > > > > > dl-linux-imx <linux- [email protected]>; Bartosz Golaszewski > > > > > <[email protected]> > > > > > 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. 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
