[PATCH v8 3/4] gpio: rpmsg: add generic rpmsg GPIO driver

[Shenwei Wang]

> -----Original Message-----
> From: Andrew Lunn <andrew at lunn.ch>
> Sent: Tuesday, February 24, 2026 11:31 AM
> To: Shenwei Wang <shenwei.wang at nxp.com>
> Cc: Arnaud POULIQUEN <arnaud.pouliquen at foss.st.com>; Linus Walleij
> <linusw at kernel.org>; Bartosz Golaszewski <brgl at kernel.org>; Jonathan Corbet
> <corbet at lwn.net>; Rob Herring <robh at kernel.org>; Krzysztof Kozlowski
> <krzk+dt at kernel.org>; Conor Dooley <conor+dt at kernel.org>; Bjorn Andersson
> <andersson at kernel.org>; Mathieu Poirier <mathieu.poirier at linaro.org>; Frank Li
> <frank.li at nxp.com>; Sascha Hauer <s.hauer at pengutronix.de>; Shuah Khan
> <skhan at linuxfoundation.org>; linux-gpio at vger.kernel.org; linux-
> doc at vger.kernel.org; linux-kernel at vger.kernel.org; Pengutronix Kernel Team
> <kernel at pengutronix.de>; Fabio Estevam <festevam at gmail.com>; Peng Fan
> <peng.fan at nxp.com>; devicetree at vger.kernel.org; linux-
> remoteproc at vger.kernel.org; imx at lists.linux.dev; linux-arm-
> kernel at lists.infradead.org; dl-linux-imx <linux-imx at nxp.com>; Bartosz
> Golaszewski <brgl at bgdev.pl>
> 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
> 
> 
> > 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:
> >
> >   - 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