On Fri, 20 Feb 2026 at 11:57, Shenwei Wang <[email protected]> wrote: > > > > > -----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. >
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
