[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: Tuesday, February 24, 2026 2:47 AM
> To: Shenwei Wang <shenwei.wang at nxp.com>; Linus Walleij
> <linusw at kernel.org>
> 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 Shenwei
>
> On 2/23/26 21:33, Shenwei Wang wrote:
> >
> >
> >> -----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.
> 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
> >