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.
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
