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

Regards,
Shenwei

Sorry.

        Andrew