On Wed, 18 Mar 2026 at 12:46, Shenwei Wang [off-list ref] wrote:

quoted

-----Original Message-----
From: Mathieu Poirier <mathieu.poirier@linaro.org>
Sent: Wednesday, March 18, 2026 11:03 AM
To: Andrew Lunn <andrew@lunn.ch>
Cc: Arnaud POULIQUEN <arnaud.pouliquen@foss.st.com>; Shenwei Wang
[off-list ref]; 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]; 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
On Tue, 17 Mar 2026 at 08:11, Andrew Lunn [off-list ref] wrote:

quoted

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 agree with everything Andrew points out above.

quoted

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:

https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flwn.
net%2Fml%2Fall%2F20250922200413.309707-3-

shenwei.wang%40nxp.com%2F&dat

quoted

a=05%7C02%7Cshenwei.wang%40nxp.com%7C4b8879a9c89a4a831cf508de850
7de18%

quoted

7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C639094465992371367%
7CUnkn

quoted

own%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIl
AiOiJX

quoted

aW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=s8tl8n
m3eD

quoted

9l%2FetyyE%2FPWwJh4wQalaaHr4OEwzpQ7NY%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.

I have made this point clear before: modeling legacy protocols in mainline doesn't
scale.  Mainline uses a single generic protocol, and yes, it means breaking legacy
protocols.  This is the cost of moving to a mainline kernel.  If people want to use
the legacy firmware, they must stick with a legacy kernel.

quoted

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?

NAK

quoted

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

NAK

quoted

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

Nothing will get merged in the RPMSG subsystem that includes support for the
legacy protocol.  Not today, not in a month, not in 5 years.

@Mathieu,
Your tone is unnecessary. If you believe this driver must
comply with a specific virtio protocol, then please point to the exact
specification instead of making blanket statements.

If virtio is the direction you prefer, you are of course free to propose
and implement such support yourself.

My patches are contributed in good faith to improve the ecosystem, and
this work clearly belongs to the GPIO subsystem. I don't understand why
you are asserting authority here without providing any technical
justification.

All arguments have already been presented to you, we are now going in circles.

I am happy to look at a new revision of this work that complies with
the comments Andrew, Arnaud and I provided.  I will not engage with
you or your work until that time comes.

@Linus Walleij,
From a technical standpoint, this GPIO driver is no different from
gpio-mxc, gpio-omap, or gpio-rda. If the concern is simply the use of
the word “generic” in the name, I’m perfectly fine reverting it to an
NXP‑specific driver.

If maintaining a private GPIO driver is no longer acceptable going
forward, that’s also fine — we can stop the discussion here. If you think
there are still technical limitations in the driver itself, I’m more than
willing to continue improving it.

But the goal is not to create a driver for another protocol that someone
claims perfect.

Thanks,
Shenwei

quoted

quoted

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.

Strong vote for 3.

quoted

     Andrew