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

[Shenwei Wang]

> -----Original Message-----
> From: Andrew Lunn <andrew@xxxxxxx>
> Sent: Tuesday, February 24, 2026 11:31 AM
> To: Shenwei Wang <shenwei.wang@xxxxxxx>
> Cc: Arnaud POULIQUEN <arnaud.pouliquen@xxxxxxxxxxx>; Linus Walleij
> <linusw@xxxxxxxxxx>; Bartosz Golaszewski <brgl@xxxxxxxxxx>; Jonathan Corbet
> <corbet@xxxxxxx>; Rob Herring <robh@xxxxxxxxxx>; Krzysztof Kozlowski
> <krzk+dt@xxxxxxxxxx>; Conor Dooley <conor+dt@xxxxxxxxxx>; Bjorn Andersson
> <andersson@xxxxxxxxxx>; Mathieu Poirier <mathieu.poirier@xxxxxxxxxx>; Frank Li
> <frank.li@xxxxxxx>; Sascha Hauer <s.hauer@xxxxxxxxxxxxxx>; Shuah Khan
> <skhan@xxxxxxxxxxxxxxxxxxx>; linux-gpio@xxxxxxxxxxxxxxx; linux-
> doc@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Pengutronix Kernel Team
> <kernel@xxxxxxxxxxxxxx>; Fabio Estevam <festevam@xxxxxxxxx>; Peng Fan
> <peng.fan@xxxxxxx>; devicetree@xxxxxxxxxxxxxxx; linux-
> remoteproc@xxxxxxxxxxxxxxx; imx@xxxxxxxxxxxxxxx; linux-arm-
> kernel@xxxxxxxxxxxxxxxxxxx; dl-linux-imx <linux-imx@xxxxxxx>; Bartosz
> Golaszewski <brgl@xxxxxxxx>
> 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