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