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

[Mathieu Poirier]

On Fri, 20 Feb 2026 at 11:57, Shenwei Wang <shenwei.wang at nxp.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Andrew Lunn <andrew at lunn.ch>
> > Sent: Friday, February 20, 2026 11:45 AM
> > To: Shenwei Wang <shenwei.wang at nxp.com>
> > Cc: Arnaud POULIQUEN <arnaud.pouliquen at foss.st.com>; Linus Walleij
> > <linusw at kernel.org>; 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
> > > If there are concerns about specific design elements within the
> > > driver, I’m happy to address those, but redesigning the hardware/firmware
> > interface is not something this series can solve.
> >
> > Then i think you are limited to using the out of tree driver.
> >
>
> Thanks for the feedback.
>
> To clarify: is Linux moving toward supporting only fully open hardware platforms? I’m
> not aware of any rule that prevents a company from upstreaming a driver that implements
> support for an existing hardware/firmware interface.
>
> 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.
>

The HW can't be changed but firmware can.  It is not realistic to
think upstream can accommodate all the quirks happening in downstream
trees - this approach simply doesn't scale.

As if I wasn't clear enough already (along with many others), the
current implementation will not be merged upstream for reasons that
have been amply discussed.  You either comply with the comments we
provided or use the existing out of tree driver.

> Regards,
> Shenwei
>
> > Sorry.
> >
> >         Andrew