On Wed, Feb 25, 2026 at 08:31:33PM +0000, Shenwei Wang wrote: > > > > -----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. >
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
