On Mon, Feb 23, 2026 at 03:24:43PM +0100, Arnaud POULIQUEN wrote: > On 2/22/26 15:48, Linus Walleij wrote: > > On Fri, Feb 20, 2026 at 7:57 PM Shenwei Wang <[email protected]> wrote: [..] > > > > 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). >
Could the virtio-based mechanism be used directly (without rpmsg)? If not, it would be good to derive a generic rpmsg-gpio protocol from the virtio protocol, and land implementations of this in e.g. Linux and Zephyr to establish that option. Regards, Bjorn > > 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 >
