> -----Original Message----- > From: Arnaud POULIQUEN <[email protected]> > Sent: Tuesday, February 24, 2026 2:47 AM > To: Shenwei Wang <[email protected]>; Linus Walleij > <[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 Shenwei > > On 2/23/26 21:33, Shenwei Wang wrote: > > > > > >> -----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. > This looks reasonable to me, but I am not a maintainer, so I will let > maintainers > share their opinions on your proposition. >
Hi Arnaud, Glad to hear you find this approach reasonable. To be more specific, I’m proposing to do the following modifications for the protocol: - remove the “id” field (Message ID Code) - remove the “reserved[5]” field - and also reorder the fields so that port_idx appears before pin_idx If you think additional fields should be removed or adjusted, please let me know. Thanks, Shenwei > Please note that you have also to answer to Bjorn and Mathieu about the > rational > to use RPMsg instead of the virtio protocol. > > For the ST platform, the main advantage of RPMsg is the ability to mix buses > on > one virtio interface, whereas Virtio requires allocating vrings and mailbox > channels per Virtio type. When data rate is not the priority, RPMsg may be > preferable. > > Another limitation e observed, when prototyping a virtio-i2c between Linux > and a > remote processor is the allocation of specific DMA memory region shared > between the processors[1]. > > [1] > https://github.co/ > m%2Farnopo%2Flinux%2Fcommit%2Fae47a1cbf95125ab10952283622653d626e > 56e6a&data=05%7C02%7Cshenwei.wang%40nxp.com%7Cdcff50d0e65541164d > b908de73814b8f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6390 > 75196360168552%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWU > sIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D% > 7C0%7C%7C%7C&sdata=HcTtPbkXm%2BTDwrmgxWj5zwBCGE9Jp3fj9AWlBriw% > 2BRY%3D&reserved=0 > > Thanks and regards, > Arnaud > > > > > 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 > >
