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

[Shenwei Wang]

> -----Original Message-----
> From: Arnaud POULIQUEN <arnaud.pouliquen@xxxxxxxxxxx>
> Sent: Monday, February 23, 2026 8:25 AM
> To: Linus Walleij <linusw@xxxxxxxxxx>; Shenwei Wang
> <shenwei.wang@xxxxxxx>
> Cc: Andrew Lunn <andrew@xxxxxxx>; Bartosz Golaszewski <brgl@xxxxxxxxxx>;
> Jonathan Corbet <corbet@xxxxxxx>; Rob Herring <robh@xxxxxxxxxx>; Krzysztof
> Kozlowski <krzk+dt@xxxxxxxxxx>; Conor Dooley <conor+dt@xxxxxxxxxx>; Bjorn
> Andersson <andersson@xxxxxxxxxx>; Mathieu Poirier
> <mathieu.poirier@xxxxxxxxxx>; Frank Li <frank.li@xxxxxxx>; Sascha Hauer
> <s.hauer@xxxxxxxxxxxxxx>; Shuah Khan <skhan@xxxxxxxxxxxxxxxxxxx>; linux-
> gpio@xxxxxxxxxxxxxxx; linux-doc@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
> Pengutronix Kernel Team <kernel@xxxxxxxxxxxxxx>; Fabio Estevam
> <festevam@xxxxxxxxx>; Peng Fan <peng.fan@xxxxxxx>;
> devicetree@xxxxxxxxxxxxxxx; linux-remoteproc@xxxxxxxxxxxxxxx;
> imx@xxxxxxxxxxxxxxx; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; dl-linux-imx <linux-
> imx@xxxxxxx>; Bartosz Golaszewski <brgl@xxxxxxxx>
> 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@xxxxxxx>
> 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