> -----Original Message----- > From: Andrew Lunn <[email protected]> > Sent: Friday, February 20, 2026 11:45 AM > To: Shenwei Wang <[email protected]> > Cc: Arnaud POULIQUEN <[email protected]>; Linus Walleij > <[email protected]>; Bartosz Golaszewski <[email protected]>; Jonathan Corbet > <[email protected]>; Rob Herring <[email protected]>; Krzysztof Kozlowski > <[email protected]>; Conor Dooley <[email protected]>; Bjorn Andersson > <[email protected]>; Mathieu Poirier <[email protected]>; Frank Li > <[email protected]>; Sascha Hauer <[email protected]>; Shuah Khan > <[email protected]>; [email protected]; linux- > [email protected]; [email protected]; Pengutronix Kernel Team > <[email protected]>; Fabio Estevam <[email protected]>; Peng Fan > <[email protected]>; [email protected]; linux- > [email protected]; [email protected]; linux-arm- > [email protected]; dl-linux-imx <[email protected]>; Bartosz > Golaszewski <[email protected]> > 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. Regards, Shenwei > Sorry. > > Andrew
