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

[Shenwei Wang]

> -----Original Message-----
> From: Mathieu Poirier <mathieu.poirier at linaro.org>
> Sent: Tuesday, February 24, 2026 12:10 PM
> To: Shenwei Wang <shenwei.wang at nxp.com>
> Cc: Bjorn Andersson <andersson at kernel.org>; Arnaud POULIQUEN
> <arnaud.pouliquen at foss.st.com>; Linus Walleij <linusw at kernel.org>; Andrew
> Lunn <andrew at lunn.ch>; Bartosz Golaszewski <brgl at kernel.org>; Jonathan
> Corbet <corbet at lwn.net>; Rob Herring <robh at kernel.org>; Krzysztof Kozlowski
> <krzk+dt at kernel.org>; Conor Dooley <conor+dt at kernel.org>; Frank Li
> <frank.li at nxp.com>; Sascha Hauer <s.hauer at pengutronix.de>; Shuah Khan
> <skhan at linuxfoundation.org>; linux-gpio at vger.kernel.org; linux-
> doc at vger.kernel.org; linux-kernel at vger.kernel.org; Pengutronix Kernel Team
> <kernel at pengutronix.de>; Fabio Estevam <festevam at gmail.com>; Peng Fan
> <peng.fan at nxp.com>; devicetree at vger.kernel.org; linux-
> remoteproc at vger.kernel.org; imx at lists.linux.dev; linux-arm-
> kernel at lists.infradead.org; dl-linux-imx <linux-imx at nxp.com>; Bartosz
> Golaszewski <brgl at bgdev.pl>
> Subject: [EXT] Re: [PATCH v8 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
> On Tue, 24 Feb 2026 at 08:56, Shenwei Wang <shenwei.wang at nxp.com> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Bjorn Andersson <andersson at kernel.org>
> > > Sent: Monday, February 23, 2026 8:43 AM
> > > To: Arnaud POULIQUEN <arnaud.pouliquen at foss.st.com>
> > > Cc: Linus Walleij <linusw at kernel.org>; Shenwei Wang
> > > <shenwei.wang at nxp.com>; Andrew Lunn <andrew at lunn.ch>; Bartosz
> > > Golaszewski <brgl at kernel.org>; Jonathan Corbet <corbet at lwn.net>; Rob
> > > Herring <robh at kernel.org>; Krzysztof Kozlowski <krzk+dt at kernel.org>;
> > > Conor Dooley <conor+dt at kernel.org>; Mathieu Poirier
> > > <mathieu.poirier at linaro.org>; Frank Li <frank.li at nxp.com>; Sascha
> > > Hauer <s.hauer at pengutronix.de>; Shuah Khan
> > > <skhan at linuxfoundation.org>; linux-gpio at vger.kernel.org; linux-
> > > doc at vger.kernel.org; linux-kernel at vger.kernel.org; Pengutronix
> > > Kernel Team <kernel at pengutronix.de>; Fabio Estevam
> > > <festevam at gmail.com>; Peng Fan <peng.fan at nxp.com>;
> > > devicetree at vger.kernel.org; linux- remoteproc at vger.kernel.org;
> > > imx at lists.linux.dev; linux-arm- kernel at lists.infradead.org;
> > > dl-linux-imx <linux-imx at nxp.com>; Bartosz Golaszewski
> > > <brgl at bgdev.pl>
> > > Subject: [EXT] Re: [PATCH v8 3/4] gpio: rpmsg: add generic rpmsg
> > > GPIO driver On Mon, Feb 23, 2026 at 03:24:43PM +0100, Arnaud POULIQUEN
> wrote:
> > > > On 2/22/26 15:48, Linus Walleij wrote:
> > > > > On Fri, Feb 20, 2026 at 7:57 PM Shenwei Wang
> > > > > <shenwei.wang at nxp.com>
> > > wrote:
> > > [..]
> > > > >
> > > > > Is it generic? If it is not, let's call it "NXP rpmsg GPIO driver"
> > > > > and rename files etc accordingly. Maybe it can share code with
> > > > > the actual generic RPMSG driver once that arrives, that is more
> > > > > of a library
> > > question.
> > > >
> > > > I would like to (re)express my concerns regarding the creation of
> > > > an NXP-specific driver. To clarify my concerns, ST, like probably
> > > > some other SoC vendors, has rpmsg-gpio and rpmsg-i2c drivers in
> > > > downstream with plans to upstream them.
> > > >
> > > > If we proceed in this direction:
> > > >
> > > > -Any vendor wishing to upstream an rpmsg-gpio driver might submit
> > > > their own platform-specific version.
> > > >
> > > > - If NXP upstreams other rpmsg drivers, these will likely remain
> > > > NXP-centric to maintain compatibility with their legacy firmware
> > > > and the nxp-rpmsg-gpio driver, leading to platform-specific
> > > > versions in several
> > > frameworks.
> > > >
> > > > - The implementation will impact not only the Linux side but also
> > > > the remote side. Indeed, some operating systems like Zephyr or
> > > > NuttX implement the rpmsg device side (Zephyr already implements
> > > > the
> > > > rpmsg-tty)
> > > >
> > > > Maintaining a generic approach for RPMsg, similar to what is done
> > > > for Virtio, seems to me a more reliable solution, even though it
> > > > may induce some downstream costs (ST would also need to break
> > > > compatibility with legacy ST remote proc firmware).
> > > >
> > >
> > > Could the virtio-based mechanism be used directly (without rpmsg)?
> > >
> >
> > Technically, yes—it's possible to use the virtio mechanism directly without
> rpmsg.
> > It’s a bit like talking straight to the IP layer without involving TCP
> > or UDP: doable, but at a lower‑level approach.
> >
> > As for the idea of gpio‑virtio, which could be an optional solution
> > that certain customers might prefer. I recall hearing this idea from
> > Mathieu originally, though I’m not sure whether he plans to implement it.
> >
> 
> As Daniel pointed out, gpio-virtio is already available and already includes a
> protocol that is generic - no need to redefine a new one as this set is trying to.
> 
> As mentioned in a previous email, I understand some implementations will have
> restricted memory and need to use RPMSG.  For those cases a generic rpmsg-gpio

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.

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

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