> -----Original Message----- > From: Arnaud POULIQUEN <[email protected]> > Sent: Monday, February 23, 2026 8:25 AM > To: Linus Walleij <[email protected]>; Shenwei Wang > <[email protected]> > Cc: Andrew Lunn <[email protected]>; Bartosz Golaszewski <[email protected]>; > Jonathan Corbet <[email protected]>; Rob Herring <[email protected]>; Krzysztof > Kozlowski <[email protected]>; Conor Dooley <[email protected]>; Bjorn > Andersson <[email protected]>; Mathieu Poirier > <[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 > Hello Linus, > > On 2/22/26 15:48, Linus Walleij wrote: > > On Fri, Feb 20, 2026 at 7:57 PM Shenwei Wang <[email protected]> > 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
