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

[Shenwei Wang]

> -----Original Message-----
> From: Arnaud POULIQUEN <arnaud.pouliquen at foss.st.com>
> Sent: Monday, February 23, 2026 8:25 AM
> To: Linus Walleij <linusw at kernel.org>; Shenwei Wang
> <shenwei.wang at nxp.com>
> Cc: 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>; Bjorn
> Andersson <andersson 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
> Hello Linus,
> 
> 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:
> >
> >> Given that, I’d like to hear from the GPIO subsystem maintainers —
> >> @Linus Walleij and @Bartosz Golaszewski — on whether a driver that
> >> works with the current hardware/firmware design could still be
> >> acceptable for upstream inclusion. My understanding is that upstream
> generally supports existing, real-world hardware as long as the driver meets
> subsystem standards.
> >
> > What a swell party this has become.
> >
> > In this kind of situations I usually refer to
> > Documentation/process/management-style.rst
> >
> 
> Thank you for pointing out the document, I was not aware of its existence. Very
> informative!
> That help me to understand you proposal below.
> 
> 
> > What is the message I as a maintainer is getting from NXP regarding
> > "gpio: rpmsg: add generic rpmsg GPIO driver"?
> >
> > Arnaud, who is the only person in this discussion who actually wrote a
> > standard RPMSG driver (drivers/tty/rpmsg_tty.c), must ACK this patch
> > if it wants to call itself a "generic" RPMSG GPIO driver, if he does
> > not, then it isn't.
> 
> In Fact there are already 2 "generic" drivers, the second one it the
> drivers/rpmsg/rpmsg_char.c, both are used on several platforms.
> 
> It is in my plan to test the rpmsg-gpio on ST platform if we go with the generic
> approach.
> 
> >
> > 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.
> 

Linus, thank you for jumping in and providing the guidance.

I would like to clarify one point here: what we are discussing now is not whether the 
driver itself is generic, but rather that the current protocol is not as perfect as Arnaud 
would expect, since it contains a few fields that may not be required on their platforms.

Arnaud, if you agree with the points above, my proposal is the following:
 - Remove the fields you mentioned in the protocol and update the driver accordingly so 
that we can establish a true baseline for a generic implementation we all agree.
 - Then prepare a separate patch to add support for existing NXP platforms by introducing 
the necessary fix‑up functions.

Please let me know if this approach works for you. My goal is to find a solution that works for 
everyone — even though I know that pleasing everyone is almost impossible.

Thanks,
Shenwei

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