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

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

quoted

-----Original Message-----
From: Andrew Lunn <andrew@lunn.ch>
Sent: Friday, February 20, 2026 11:45 AM
To: Shenwei Wang <shenwei.wang@nxp.com>
Cc: Arnaud POULIQUEN <arnaud.pouliquen@foss.st.com>; Linus Walleij
[off-list ref]; 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 [off-list ref]; Bartosz
Golaszewski [off-list ref]
Subject: [EXT] Re: [PATCH v8 3/4] gpio: rpmsg: add generic rpmsg GPIO driver

quoted

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

quoted

Sorry.

        Andrew