Re: [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@xxxxxxx> wrote:
>
>
>
> > -----Original Message-----
> > From: Andrew Lunn <andrew@xxxxxxx>
> > Sent: Friday, February 20, 2026 11:45 AM
> > To: Shenwei Wang <shenwei.wang@xxxxxxx>
> > Cc: Arnaud POULIQUEN <arnaud.pouliquen@xxxxxxxxxxx>; Linus Walleij
> > <linusw@xxxxxxxxxx>; Bartosz Golaszewski <brgl@xxxxxxxxxx>; Jonathan Corbet
> > <corbet@xxxxxxx>; Rob Herring <robh@xxxxxxxxxx>; Krzysztof Kozlowski
> > <krzk+dt@xxxxxxxxxx>; Conor Dooley <conor+dt@xxxxxxxxxx>; Bjorn Andersson
> > <andersson@xxxxxxxxxx>; Mathieu Poirier <mathieu.poirier@xxxxxxxxxx>; Frank Li
> > <frank.li@xxxxxxx>; Sascha Hauer <s.hauer@xxxxxxxxxxxxxx>; Shuah Khan
> > <skhan@xxxxxxxxxxxxxxxxxxx>; linux-gpio@xxxxxxxxxxxxxxx; linux-
> > doc@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Pengutronix Kernel Team
> > <kernel@xxxxxxxxxxxxxx>; Fabio Estevam <festevam@xxxxxxxxx>; Peng Fan
> > <peng.fan@xxxxxxx>; devicetree@xxxxxxxxxxxxxxx; linux-
> > remoteproc@xxxxxxxxxxxxxxx; imx@xxxxxxxxxxxxxxx; linux-arm-
> > kernel@xxxxxxxxxxxxxxxxxxx; dl-linux-imx <linux-imx@xxxxxxx>; Bartosz
> > Golaszewski <brgl@xxxxxxxx>
> > 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