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

-----Original Message-----
From: Arnaud POULIQUEN <arnaud.pouliquen@foss.st.com>
Sent: Tuesday, February 24, 2026 2:47 AM
To: Shenwei Wang <shenwei.wang@nxp.com>; Linus Walleij
[off-list ref]
Cc: Andrew Lunn <andrew@lunn.ch>; Bartosz Golaszewski <brgl@kernel.org>;
Jonathan Corbet [off-list ref]; Rob Herring [off-list ref]; Krzysztof
Kozlowski [off-list ref]; Conor Dooley [off-list ref]; Bjorn
Andersson [off-list ref]; Mathieu Poirier
[off-list ref]; Frank Li [off-list ref]; Sascha Hauer
[off-list ref]; Shuah Khan [off-list ref]; linux-
gpio@vger.kernel.org; linux-doc@vger.kernel.org; linux-kernel@vger.kernel.org;
Pengutronix Kernel Team [off-list ref]; Fabio Estevam
[off-list ref]; Peng Fan [off-list ref];
devicetree@vger.kernel.org; linux-remoteproc@vger.kernel.org;
imx@lists.linux.dev; linux-arm-kernel@lists.infradead.org; dl-linux-imx <linux-
imx@nxp.com>; Bartosz Golaszewski [off-list ref]
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:

quoted

quoted

-----Original Message-----
From: Arnaud POULIQUEN <arnaud.pouliquen@foss.st.com>
Sent: Monday, February 23, 2026 8:25 AM
To: Linus Walleij <linusw@kernel.org>; Shenwei Wang
[off-list ref]
Cc: Andrew Lunn <andrew@lunn.ch>; Bartosz Golaszewski
[off-list ref]; Jonathan Corbet [off-list ref]; Rob Herring
[off-list ref]; Krzysztof Kozlowski [off-list ref]; Conor
Dooley [off-list ref]; Bjorn Andersson [off-list ref];
Mathieu Poirier [off-list ref]; Frank Li
[off-list ref]; Sascha Hauer [off-list ref]; Shuah Khan
[off-list ref]; linux- gpio@vger.kernel.org;
linux-doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix
Kernel Team [off-list ref]; Fabio Estevam
[off-list ref]; Peng Fan [off-list ref];
devicetree@vger.kernel.org; linux-remoteproc@vger.kernel.org;
imx@lists.linux.dev; linux-arm-kernel@lists.infradead.org;
dl-linux-imx <linux- imx@nxp.com>; Bartosz Golaszewski
[off-list ref]
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:

quoted

On Fri, Feb 20, 2026 at 7:57 PM Shenwei Wang [off-list ref]

wrote:

quoted

quoted

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.

quoted

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.

quoted

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.

quoted

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.

quoted

quoted

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.

quoted

quoted

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.

quoted

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.

quoted

  - 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

quoted

Thanks,
Shenwei

quoted

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.

quoted

quoted

- The implementation will impact not only the Linux side but also the remote

side.

quoted

quoted

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

quoted

Yours,
Linus Walleij