> -----Original Message-----
> From: Andrew Lunn <[email protected]>
> Sent: Tuesday, February 24, 2026 11:31 AM
> To: Shenwei Wang <[email protected]>
> Cc: Arnaud POULIQUEN <[email protected]>; Linus Walleij
> <[email protected]>; Bartosz Golaszewski <[email protected]>; Jonathan Corbet
> <[email protected]>; Rob Herring <[email protected]>; Krzysztof Kozlowski
> <[email protected]>; Conor Dooley <[email protected]>; Bjorn Andersson
> <[email protected]>; Mathieu Poirier <[email protected]>; Frank Li
> <[email protected]>; Sascha Hauer <[email protected]>; Shuah Khan
> <[email protected]>; [email protected]; linux-
> [email protected]; [email protected]; Pengutronix Kernel Team
> <[email protected]>; Fabio Estevam <[email protected]>; Peng Fan
> <[email protected]>; [email protected]; linux-
> [email protected]; [email protected]; linux-arm-
> [email protected]; dl-linux-imx <[email protected]>; Bartosz
> Golaszewski <[email protected]>
> 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
