-----Original Message-----
From: Andrew Lunn <andrew@lunn.ch>
Sent: Tuesday, February 24, 2026 11:31 AM
To: Shenwei Wang <shenwei.wang@nxp.com>
Cc: Arnaud POULIQUEN <arnaud.pouliquen@foss.st.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 v8 3/4] gpio: rpmsg: add generic rpmsg GPIO driver

Caution: This is an external email. Please take care when clicking links or opening
attachments. When in doubt, report the message using the 'Report this email'
button

quoted

Hi Arnaud,
Glad to hear you find this approach reasonable.
To be more specific, I’m proposing to do the following modifications for the

protocol:

quoted

  - remove the “id” field (Message ID Code)
  - remove the “reserved[5]” field
  - and also reorder the fields so that port_idx appears before
pin_idx

If you think additional fields should be removed or adjusted, please let me

know.

I would squash head and body into one. Remove vendor and version. Do we need
both cmd and type? It seems like they can be combined. And is port_idx needed?
Don't you just instantiate more instances of the device, one per port. That is how
you would do it with MMIO GPIOs.

I don’t think we can remove port_idx if the protocol is expected to support multiple 
instances. If you only ever support a single instance, then sure, it becomes redundant—but 
imposing a single‑instance limitation on a generic protocol doesn’t seem appropriate.

Regarding type, it’s needed, especially for the in packets. There are two distinct kinds of incoming 
packets: notification‑in and reply‑in. Because of that differences, Combining cmd and type would 
blur that distinction and complicate the implementation.

Thanks,
Shenwei

struct gpio_rpmsg_packet {
        u8 cmd;
        u8 pin;
        union {
                u8 event;
                u8 retcode;
                u8 value;
        } out;
        union {
                u8 wakeup;
                u8 value;
        } in;
}

4 bytes, a nice size.

#define GPIO_RPMSG_CMD_DIR_INPUT        1
#define GPIO_RPMSG_CMD_DIR_OUTPUT       2
#define GPIO_RPMSG_CMD_GET_DIR          3
#define GPIO_RPMSG_CMD_GET              4
#define GPIO_RPMSG_CMD_SET              5

These map onto the gpio_chip ops. And i leave space for the _multiple ops if they
are needed in the future.

#define GPIO_PRMSG_CMD_INTR_CONFIG      32
#define GPIO_PRMSG_CMD_INTR_EVENT       33

And then interrupt handling. These are less obvious, struct irq_chip has a lot more
ops, so i'm not very confident this is sufficient.

        Andrew