> -----Original Message-----
> From: Mathieu Poirier <[email protected]>
> Sent: Tuesday, February 24, 2026 2:41 PM
> To: Shenwei Wang <[email protected]>
> Cc: Bjorn Andersson <[email protected]>; Arnaud POULIQUEN
> <[email protected]>; Linus Walleij <[email protected]>; Andrew
> Lunn <[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]>; [email protected]; linux-
> [email protected]; [email protected]; Pengutronix Kernel Team
> <[email protected]>; Fabio Estevam <[email protected]>; Peng Fan
> <[email protected]>; [email protected]; linux-
> [email protected]; [email protected]; linux-arm-
> [email protected]; dl-linux-imx <[email protected]>; Bartosz
> Golaszewski <[email protected]>
> Subject: [EXT] Re: [PATCH v8 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
> > > -----Original Message-----
> > > From: Mathieu Poirier <[email protected]>
> > > Sent: Tuesday, February 24, 2026 12:10 PM
> > > To: Shenwei Wang <[email protected]>
> > > Cc: Bjorn Andersson <[email protected]>; Arnaud POULIQUEN
> > > <[email protected]>; Linus Walleij <[email protected]>;
> > > Andrew Lunn <[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]>;
> > > [email protected]; linux- [email protected];
> > > [email protected]; Pengutronix Kernel Team
> > > <[email protected]>; Fabio Estevam <[email protected]>; Peng
> > > Fan <[email protected]>; [email protected]; linux-
> > > [email protected]; [email protected]; linux-arm-
> > > [email protected]; dl-linux-imx <[email protected]>;
> > > Bartosz Golaszewski <[email protected]>
> > > Subject: [EXT] Re: [PATCH v8 3/4] gpio: rpmsg: add generic rpmsg
> > > GPIO driver On Tue, 24 Feb 2026 at 08:56, Shenwei Wang
> <[email protected]> wrote:
> > > >
> > > >
> > > >
> > I think this highlights why some customers prefer RPMSG over using
> > virtio directly. Limited system resources and development efficiency
> > are the two main reasons that make RPMSG a better fit for certain
> environments.
> >
> > > protocol should be derived from gpio-virtio that would only deal
> > > with breaking down the standard gpio-virtio protocol into something
> > > digestible by RPMSG. That was Bjorn's point in an earlier message.
> > > This will allow to use the same interface and be flexible in how we
> > > want to talk to the transport medium, i.e pure gpio- virtio or rpmsg-gpio.
> > >
> >
> > Once the remoteproc chooses to expose devices through an RPMSG‑based
> > protocol, deriving another driver from gpio‑virtio doesn’t really make
> > sense. That would essentially mean re‑implementing parts of RPMSG yourself
> instead of using existing one.
> >
>
> We clearly do not understand each other.
>
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 -> ???
This is your comments: "For those cases a generic rpmsg-gpio protocol should
be derived from gpio-virtio"
Please explain how you would design your generic rpmsg-gpio driver which is
derived
From gpio-virtio?
Thanks,
Shenwei
> > > Fortunately RPMSG already uses channels to differentiate between
> > > traffic, no need to multiplex everything on the same channel. That too
> > > needs
> to go.
> > >
> > > > As the chip vendor, NXP’s role is to provide all possible options
> > > > and let customers choose the approach that best fits their needs;
> > > > we don’t make
> > > that decision for them.
> > >
> > > As kernel maintainers, our role is to advise on designs that are
> > > generic, simple, maintainable and stand the test of time.
> > >
> >
> > These adjectives only make sense within the context of a specific use
> > case. Different systems have different constraints, and people choose
> > a particular solution for valid reasons based on their requirements.
> >
>
> You can choose whatever solution you want, that is entirely up to you.
> Maintainers can also choose to reject that solution for mainline Linux, which
> is
> exactly what we are doing.
>
> > Please respect their efforts.
> >
> > Thanks,
> > Shenwei
> >
> > > >
> > > > Thanks,
> > > > Shenwei
> > > >
> > > > >
> > > > > If not, it would be good to derive a generic rpmsg-gpio protocol
> > > > > from the virtio protocol, and land implementations of this in e.g.
> > > > > Linux and Zephyr to establish that option.
> > > > >
> > > > > Regards,
> > > > > Bjorn
> > > > >
> > > > > >
> > > > > > In the end, I am just trying to influence the direction for
> > > > > > RPMsg, but based on the discussions in this thread, it seems
> > > > > > others share similar expectations, which should probably be taken
> > > > > > into
> account as well.
> > > > > >
> > > > > > Thanks and Regards,
> > > > > > Arnaud
> > > > > >
> > > > > >
> > > > > > I just want to
> > > > > >
> > > > > > >
> > > > > > > Yours,
> > > > > > > Linus Walleij
> > > > > >
