-----Original Message-----
From: Andrew Lunn <andrew@lunn.ch>
Sent: Tuesday, March 17, 2026 9:12 AM
To: Arnaud POULIQUEN <arnaud.pouliquen@foss.st.com>
Cc: Shenwei Wang <shenwei.wang@nxp.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 v12 3/5] gpio: rpmsg: add generic rpmsg GPIO driver

quoted

quoted

+struct rpmsg_gpio_info {
+   struct rpmsg_device *rpdev;
+   struct rpmsg_gpio_packet *reply_msg;
+   struct completion cmd_complete;
+   struct mutex lock;
+   void **port_store;
+};

Except if I missunderstood Mathieu and Bjorn's request:
"reuse all the design-work done in the gpio-virtio"
We should find similar structures here to those defined in
virtio_gpio.h.
struct rpmsg_gpio_config {
      __le16 ngpio;
      __u8 padding[2];
      __le32 gpio_names_size;
};

/* Virtio GPIO Request / Response */
struct virtio_gpio_request {
      __le16 type;
      __le16 gpio;
      __le32 value;
};

The core of the issue is that Shenwei is stone walling any change which makes it
hard to keep the legacy firmware. It is possible to use these structures, but it
makes the extra code Shenwei needs to translate this protocol to the legacy
protocol more difficult. It might need to keep state, etc.

I’m fully open to reasonable changes, but duplicating these structures is not helpful.
The whole point of aligning with gpio‑virtio is to keep the low‑level command and information 
exchange identical, so the behavior on both sides could remain consistent. This makes it 
possible to reuse the backend implementation on the other side easily.

Two points...

The firmware implements more than GPIO. There is definitely I2C as well, the
first version of the patch has bits of I2C code. Looking at:

Please keep the discussion focused on the GPIO interface.
In the current implementation, there is nothing beyond GPIO, and you will not find 
any information or indication of other interfaces such as I2C here.

Shenwei

https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flwn.net%2
Fml%2Fall%2F20250922200413.309707-3-
shenwei.wang%40nxp.com%2F&data=05%7C02%7Cshenwei.wang%40nxp.com
%7C249345db2cda4e35e09c08de842f2ac2%7C686ea1d3bc2b4c6fa92cd99c5c30
1635%7C0%7C0%7C639093535285629301%7CUnknown%7CTWFpbGZsb3d8eyJ
FbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWF
pbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=NlmSowKXXGqdOtAKEWXRz
AdQZaU19yJtyJyfIm%2B8ZQ0%3D&reserved=0

There is also RTC, and a few other things which don't directly map to Linux
subsystems, but maybe do have Linux drivers?

Give how much pushback there has been on the existing protocol for GPIO, it
would be wise to assume that I2C, and RTC is going to get the same amount of
pushback. If any of these three, GPIO, I2C, or RTC decide that only a new, clean
protocol will be accepted, no legacy shims, the firmware has to change, breaking
compatibility to legacy protocols, and the accepted shims become pointless
Maintenance burden.

Point two is that the customers who are pushing for these drivers to be added to
Mainline probably know that nearly nothing gets into Mainline without some
changes. There is some short term pain to swapping to Mainline because of these
changes, in this case, firmware upgrades. But in the long run, it is worth the pain
to be able to use Mainline. And those customers who don't want to upgrade the
firmware can keep with the out of tree drives.

So, what are our choices?

1) We accept the code as it is now, with the shim?

2) We keep pushing for the virtio protocol, with the shim?

3) We keep pushing for the virtio protocol, no shim, firmware changes

4) We pause GPIO where it is today, and restart all the arguments with
   the I2C driver. We can come back to the GPIO driver in a few months
   time once we have a better idea how I2C is going. And maybe we also
   need to see the watchdog driver, and argue about its protocol.

I also understand ST has a generic I2C driver nearly ready, if that gets merged
first, that probably kills the NXP I2C protocol, and maybe the NXP GPIO and RTC
protocols.

My vote is for 3. If not 3, then 4.

     Andrew