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

[Arnaud POULIQUEN <arnaud.pouliquen@foss.st.com>]

Hello Linus,

On 2/22/26 15:48, Linus Walleij wrote:
> On Fri, Feb 20, 2026 at 7:57 PM Shenwei Wang <shenwei.wang@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.

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