> -----Original Message-----
> From: Andrew Lunn <[email protected]>
> Sent: Wednesday, March 18, 2026 3:11 PM
> To: Shenwei Wang <[email protected]>
> Cc: Mathieu Poirier <[email protected]>; 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]>; 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 v12 3/5] gpio: rpmsg: add generic rpmsg GPIO driver
> 
> > @Linus Walleij,
> > From a technical standpoint, this GPIO driver is no different from
> > gpio-mxc, gpio-omap, or gpio-rda.
> 
> Yes it is different. The example you list are all silicon GPIO blocks.
> This driver is not for silicon, is a protocol spoken over rpmsg.  The concept 
> of two

A GPIO driver only needs to follow its defined interface, whether that 
interface is exposed 
via registers or via rpmsg. It doesn't need to know whether the backend 
implementation is 
hardware or firmware, and stable firmware can behave just like hardened logic 
from the 
driver's perspective.

> CPUs connected by rpmsg in a SoC is used by a number of vendors. Look in
> Documentation/devicetree/bindings/remoteproc you see:
> 
> amlogic, fsl, ingenic, mtk, qcom, reneses, st, ti, wkup and xlnx.
> 
> We want one generic protocol/implementation of GPIO over rpmsg which all

If you believe the current GPIO driver isn't generic, could you point to a real 
example 
that shows where it doesn't fit?

Thanks,
Shenwei 

> these vendors will use. That means we have one GPIO driver, not 10 drivers to
> maintain for the next 10-20 years. It also means those 10 vendors have 1/10 
> of a
> driver they need to maintain for the next 10-20 years. And likely less bugs 
> to deal
> with, since the driver is more heavily tested by 10 vendors, etc.
> 
>      Andrew

Reply via email to