[PATCH v13 0/4] Enable Remote GPIO over RPMSG on i.MX Platform

[PATCH v13 0/4] Enable Remote GPIO over RPMSG on i.MX Platform

[Shenwei Wang]

Support the remote devices on the remote processor via the RPMSG bus on
i.MX platform.

Changes in v13:
 - drop the support for legacy NXP firmware.
 - remove the fixed_up hooks from the rpmsg gpio driver.
 - code cleanup.

Changes in v12:
 - Fixed the "underline" warning reported by Randy.

Changes in v11:
 - Expand RPMSG for the first time per Shuah's review comment.

Changes in v10:
 - Update gpio-rpmsg.rst according to Daniel Baluta's review comments.
 - Add a kernel CONFIG for fixed up handlers and only enable it on
   i.MX products.
 - Fixed bugs reported by kernel test robot.

Changes in v9:
 - Reuse the gpio-virtio design for command and IRQ type definitions.
 - Remove msg_id, version, and vendor fields from the generic protocol.
 - Add fixed-up handlers to support legacy firmware.

Changes in v8:
 - Add "depends on REMOTEPROC" in Kconfig to fix the build error reported
   by the kernel test robot.
 - Move the .rst patch before the .yaml patch.
 - Handle the "ngpios" DT property based on Andrew's feedback.

Changes in v7:
 - Reworked the driver to use the rpmsg_driver framework instead of
   platform_driver, based on feedback from Bjorn and Arnaud.
 - Updated gpio-rpmsg.yaml and imx_rproc.yaml according to comments from
   Rob and Arnaud.
 - Further refinements to gpio-rpmsg.yaml per Arnaud's feedback.

Changes in v6:
 - make the driver more generic with the actions below:
     rename the driver file to gpio-rpmsg.c
     remove the imx related info in the function and variable names
     rename the imx_rpmsg.h to rpdev_info.h
     create a gpio-rpmsg.yaml and refer it in imx_rproc.yaml
 - update the gpio-rpmsg.rst according to the feedback from Andrew and
   move the source file to driver-api/gpio
 - fix the bug reported by Zhongqiu Han
 - remove the I2C related info

Changes in v5:
 - move the gpio-rpmsg.rst from admin-guide to staging directory after
   discussion with Randy Dunlap.
 - add include files with some code improvements per Bartosz's comments.

Changes in v4:
 - add a documentation to describe the transport protocol per Andrew's
   comments.
 - add a new handler to get the gpio direction.

Changes in v3:
 - fix various format issue and return value check per Peng 's review
   comments.
 - add the logic to also populate the subnodes which are not in the
   device map per Arnaud's request. (in imx_rproc.c)
 - update the yaml per Frank's review comments.

Changes in v2:
 - re-implemented the gpio driver per Linus Walleij's feedback by using
   GPIOLIB_IRQCHIP helper library.
 - fix various format issue per Mathieu/Peng 's review comments.
 - update the yaml doc per Rob's feedback

Shenwei Wang (4):
  docs: driver-api: gpio: rpmsg gpio driver over rpmsg bus
  dt-bindings: remoteproc: imx_rproc: Add "rpmsg" subnode support
  gpio: rpmsg: add generic rpmsg GPIO driver
  arm64: dts: imx8ulp: Add rpmsg node under imx_rproc

 .../devicetree/bindings/gpio/gpio-rpmsg.yaml  |  55 ++
 .../bindings/remoteproc/fsl,imx-rproc.yaml    |  53 ++
 Documentation/driver-api/gpio/gpio-rpmsg.rst  | 266 ++++++++
 Documentation/driver-api/gpio/index.rst       |   1 +
 arch/arm64/boot/dts/freescale/imx8ulp.dtsi    |  25 +
 drivers/gpio/Kconfig                          |  17 +
 drivers/gpio/Makefile                         |   1 +
 drivers/gpio/gpio-rpmsg.c                     | 573 ++++++++++++++++++
 8 files changed, 991 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-rpmsg.yaml
 create mode 100644 Documentation/driver-api/gpio/gpio-rpmsg.rst
 create mode 100644 drivers/gpio/gpio-rpmsg.c

--
2.43.0

[PATCH v13 1/4] docs: driver-api: gpio: rpmsg gpio driver over rpmsg bus

[Shenwei Wang]

Describes the gpio rpmsg transport protocol over the rpmsg bus between
the remote system and Linux.

Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com>
---
 Documentation/driver-api/gpio/gpio-rpmsg.rst | 266 +++++++++++++++++++
 Documentation/driver-api/gpio/index.rst      |   1 +
 2 files changed, 267 insertions(+)
 create mode 100644 Documentation/driver-api/gpio/gpio-rpmsg.rst

diff --git a/Documentation/driver-api/gpio/gpio-rpmsg.rst b/Documentation/driver-api/gpio/gpio-rpmsg.rst
new file mode 100644
index 000000000000..abfde68c9b0a
--- /dev/null
+++ b/Documentation/driver-api/gpio/gpio-rpmsg.rst
@@ -0,0 +1,266 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+GPIO RPMSG (Remote Processor Messaging) Protocol
+================================================
+
+The GPIO RPMSG transport protocol is used for communication and interaction
+with GPIO controllers on remote processors via the RPMSG bus.
+
+Message Format
+--------------
+
+The RPMSG message consists of a 6-byte packet with the following layout:
+
+.. code-block:: none
+
+   +-----+-----+-----+-----+-----+----+
+   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
+   |type |cmd  |port |line |  data    |
+   +-----+-----+-----+-----+-----+----+
+
+- **type (Message Type)**: The message type can be one of:
+
+  - 0: GPIO_RPMSG_SEND
+  - 1: GPIO_RPMSG_REPLY
+  - 2: GPIO_RPMSG_NOTIFY
+
+- **cmd**: Command code, used for GPIO_RPMSG_SEND messages.
+
+- **port**: The GPIO port (bank) index.
+
+- **line**: The GPIO line (pin) index of the port.
+
+- **data**: See details in the command description below.
+
+- **reply err**: Error code from the remote core.
+
+  - 0: Success
+  - 1: General error (Early remote software only returns this unclassified error)
+  - 2: Not supported (A command is not supported by the remote firmware)
+  - 3: Resource not available (The resource is not allocated to Linux)
+  - 4: Resource busy (The resource is already in use)
+  - 5: Parameter error
+
+
+GPIO Commands
+-------------
+
+Commands are specified in the **Cmd** field for **GPIO_RPMSG_SEND** (Type=0) messages.
+
+The SEND message is always sent from Linux to the remote firmware. Each
+SEND corresponds to a single REPLY message. The GPIO driver should
+serialize messages and determine whether a REPLY message is required. If a
+REPLY message is expected but not received within the specified timeout
+period (currently 1 second in the Linux driver), the driver should return
+-ETIMEOUT.
+
+GET_DIRECTION (Cmd=2)
+~~~~~~~~~~~~~~~~~~~~~
+
+**Request:**
+
+.. code-block:: none
+
+   +-----+-----+-----+-----+-----+----+
+   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
+   | 0   | 2   |port |line | 0   | 0  |
+   +-----+-----+-----+-----+-----+----+
+
+**Reply:**
+
+.. code-block:: none
+
+   +-----+-----+-----+-----+-----+----+
+   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
+   | 1   | 2   |port |line | err | dir|
+   +-----+-----+-----+-----+-----+----+
+
+- **err**: See above for definitions.
+
+- **dir**: Direction.
+
+  - 0: None
+  - 1: Output
+  - 2: Input
+
+SET_DIRECTION (Cmd=3)
+~~~~~~~~~~~~~~~~~~~~~
+
+**Request:**
+
+.. code-block:: none
+
+   +-----+-----+-----+-----+-----+----+
+   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
+   | 0   | 3   |port |line | dir | 0  |
+   +-----+-----+-----+-----+-----+----+
+
+- **dir**: Direction.
+
+  - 0: None
+  - 1: Output
+  - 2: Input
+
+**Reply:**
+
+.. code-block:: none
+
+   +-----+-----+-----+-----+-----+----+
+   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
+   | 1   | 3   |port |line | err | 0  |
+   +-----+-----+-----+-----+-----+----+
+
+- **err**: See above for definitions.
+
+
+GET_VALUE (Cmd=4)
+~~~~~~~~~~~~~~~~~
+
+**Request:**
+
+.. code-block:: none
+
+   +-----+-----+-----+-----+-----+----+
+   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
+   | 0   | 4   |port |line | 0   | 0  |
+   +-----+-----+-----+-----+-----+----+
+
+**Reply:**
+
+.. code-block:: none
+
+   +-----+-----+-----+-----+-----+----+
+   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
+   | 1   | 4   |port |line | err | val|
+   +-----+-----+-----+-----+-----+----+
+
+- **err**: See above for definitions.
+
+- **val**: Line level.
+
+  - 0: Low
+  - 1: High
+
+SET_VALUE (Cmd=5)
+~~~~~~~~~~~~~~~~~
+
+**Request:**
+
+.. code-block:: none
+
+   +-----+-----+-----+-----+-----+----+
+   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
+   | 0   | 5   |port |line | val | 0  |
+   +-----+-----+-----+-----+-----+----+
+
+- **val**: Output level.
+
+  - 0: Low
+  - 1: High
+
+**Reply:**
+
+.. code-block:: none
+
+   +-----+-----+-----+-----+-----+----+
+   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
+   | 1   | 5   |port |line | err | 0  |
+   +-----+-----+-----+-----+-----+----+
+
+- **err**: See above for definitions.
+
+SET_IRQ_TYPE (Cmd=6)
+~~~~~~~~~~~~~~~~~~~~
+
+**Request:**
+
+.. code-block:: none
+
+   +-----+-----+-----+-----+-----+----+
+   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
+   | 0   | 6   |port |line | val | wk |
+   +-----+-----+-----+-----+-----+----+
+
+- **val**: IRQ types.
+
+  - 0: Interrupt disabled
+  - 1: Rising edge trigger
+  - 2: Falling edge trigger
+  - 3: Both edge trigger
+  - 4: High level trigger
+  - 8: Low level trigger
+
+- **wk**: Wakeup enable.
+
+  The remote system should always aim to stay in a power-efficient state by
+  shutting down or clock-gating the GPIO blocks that aren't in use. Since
+  the remoteproc driver is responsible for managing the power states of the
+  remote firmware, the GPIO driver does not require to know the firmware's
+  running states.
+
+  When the wakeup bit is set, the remote firmware should configure the line
+  as a wakeup source. The firmware should send the notification message to
+  Linux after it is woken from the GPIO line.
+
+  - 0: Disable wakeup from GPIO
+  - 1: Enable wakeup from GPIO
+
+**Reply:**
+
+.. code-block:: none
+
+   +-----+-----+-----+-----+-----+----+
+   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
+   | 1   | 6   |port |line | err | 0  |
+   +-----+-----+-----+-----+-----+----+
+
+- **err**: See above for definitions.
+
+NOTIFY_REPLY (Cmd=10)
+~~~~~~~~~~~~~~~~~~~~~
+The reply message for the notification is optional. The remote firmware can
+implement it to simulate the interrupt acknowledgment behavior.
+
+**Request:**
+
+.. code-block:: none
+
+   +-----+-----+-----+-----+-----+----+
+   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
+   | 0   | 10  |port |line |level| 0  |
+   +-----+-----+-----+-----+-----+----+
+
+- **port**: The GPIO port (bank) index.
+
+- **line**: The GPIO line (pin) index of the port.
+
+- **level**: GPIO line status.
+
+Notification Message
+--------------------
+
+Notifications are sent by the remote core and they have
+**Type=2 (GPIO_RPMSG_NOTIFY)**:
+
+When a GPIO line asserts an interrupt on the remote processor, the firmware
+should immediately mask the corresponding interrupt source and send a
+notification message to the Linux. Upon completion of the interrupt
+handling on the Linux side, the driver should issue a
+command **SET_IRQ_TYPE** to the firmware to unmask the interrupt.
+
+A Notification message can arrive between a SEND and its REPLY message,
+and the driver is expected to handle this scenario.
+
+.. code-block:: none
+
+   +-----+-----+-----+-----+-----+----+
+   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
+   | 2   | 0   |port |line |type | 0  |
+   +-----+-----+-----+-----+-----+----+
+
+- **port**: The GPIO port (bank) index.
+
+- **line**: The GPIO line (pin) index of the port.
+
+- **type**: Optional parameter to indicate the trigger event type.
+
diff --git a/Documentation/driver-api/gpio/index.rst b/Documentation/driver-api/gpio/index.rst
index bee58f709b9a..e5eb1f82f01f 100644
--- a/Documentation/driver-api/gpio/index.rst
+++ b/Documentation/driver-api/gpio/index.rst
@@ -16,6 +16,7 @@ Contents:
    drivers-on-gpio
    bt8xxgpio
    pca953x
+   gpio-rpmsg
 
 Core
 ====
-- 
2.43.0

[PATCH v13 2/4] dt-bindings: remoteproc: imx_rproc: Add "rpmsg" subnode support

[Shenwei Wang]

Remote processors may announce multiple GPIO controllers over an RPMSG
channel. These GPIO controllers may require corresponding device tree
nodes, especially when acting as providers, to supply phandles for their
consumers.

Define an RPMSG node to work as a container for a group of RPMSG channels
under the imx_rproc node. Each subnode within "rpmsg" represents an
individual RPMSG channel. The name of each subnode corresponds to the
channel name as defined by the remote processor.

All remote devices associated with a given channel are defined as child
nodes under the corresponding channel node.

Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com>
---
 .../devicetree/bindings/gpio/gpio-rpmsg.yaml  | 55 +++++++++++++++++++
 .../bindings/remoteproc/fsl,imx-rproc.yaml    | 53 ++++++++++++++++++
 2 files changed, 108 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-rpmsg.yaml

diff --git a/Documentation/devicetree/bindings/gpio/gpio-rpmsg.yaml b/Documentation/devicetree/bindings/gpio/gpio-rpmsg.yaml
new file mode 100644
index 000000000000..6c78b6850321
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-rpmsg.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/gpio-rpmsg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Generic RPMSG GPIO Controller
+
+maintainers:
+  - Shenwei Wang <shenwei.wang@nxp.com>
+
+description:
+  On an AMP platform, some GPIO controllers are exposed by the remote processor
+  through the RPMSG bus. The RPMSG GPIO transport protocol defines the packet
+  structure and communication flow between Linux and the remote firmware. Those
+  controllers are managed via this transport protocol. For more details of the
+  protocol, check the document below.
+  Documentation/driver-api/gpio/gpio-rpmsg.rst
+
+properties:
+  compatible:
+    oneOf:
+      - items:
+          - enum:
+              - fsl,rpmsg-gpio
+          - const: rpmsg-gpio
+      - const: rpmsg-gpio
+
+  reg:
+    description:
+      The reg property represents the index of the GPIO controllers. Since
+      the driver manages controllers on a remote system, this index tells
+      the remote system which controller to operate.
+    maxItems: 1
+
+  "#gpio-cells":
+    const: 2
+
+  gpio-controller: true
+
+  interrupt-controller: true
+
+  "#interrupt-cells":
+    const: 2
+
+required:
+  - compatible
+  - reg
+  - "#gpio-cells"
+  - "#interrupt-cells"
+
+allOf:
+  - $ref: /schemas/gpio/gpio.yaml#
+
+unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
index ce8ec0119469..aea33205a881 100644
--- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
@@ -85,6 +85,34 @@ properties:
       This property is to specify the resource id of the remote processor in SoC
       which supports SCFW
 
+  rpmsg:
+    type: object
+    additionalProperties: false
+    description:
+      Represents the RPMSG bus between Linux and the remote system. Contains
+      a group of RPMSG channel devices running on the bus.
+
+    properties:
+      rpmsg-io:
+        type: object
+        additionalProperties: false
+        properties:
+          '#address-cells':
+            const: 1
+
+          '#size-cells':
+            const: 0
+
+        patternProperties:
+          "gpio@[0-9a-f]+$":
+            type: object
+            $ref: /schemas/gpio/gpio-rpmsg.yaml#
+            unevaluatedProperties: false
+
+        required:
+          - '#address-cells'
+          - '#size-cells'
+
 required:
   - compatible
 
@@ -147,5 +175,30 @@ examples:
                 &mu 3 1>;
       memory-region = <&vdev0buffer>, <&vdev0vring0>, <&vdev0vring1>, <&rsc_table>;
       syscon = <&src>;
+
+      rpmsg {
+        rpmsg-io {
+          #address-cells = <1>;
+          #size-cells = <0>;
+
+          gpio@0 {
+            compatible = "rpmsg-gpio";
+            reg = <0>;
+            gpio-controller;
+            #gpio-cells = <2>;
+            #interrupt-cells = <2>;
+            interrupt-controller;
+          };
+
+          gpio@1 {
+            compatible = "rpmsg-gpio";
+            reg = <1>;
+            gpio-controller;
+            #gpio-cells = <2>;
+            #interrupt-cells = <2>;
+            interrupt-controller;
+          };
+        };
+      };
     };
 ...
-- 
2.43.0

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

[Shenwei Wang]

On an AMP platform, the system may include two processors:
	- An MCU running an RTOS
	- An MPU running Linux

These processors communicate via the RPMSG protocol.
The driver implements the standard GPIO interface, allowing
the Linux side to control GPIO controllers which reside in
the remote processor via RPMSG protocol.

Cc: Bartosz Golaszewski <brgl@bgdev.pl>
Cc: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com>
---
 drivers/gpio/Kconfig      |  17 ++
 drivers/gpio/Makefile     |   1 +
 drivers/gpio/gpio-rpmsg.c | 573 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 591 insertions(+)
 create mode 100644 drivers/gpio/gpio-rpmsg.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 020e51e30317..4ad299fe3c6f 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -1917,6 +1917,23 @@ config GPIO_SODAVILLE
 
 endmenu
 
+menu "RPMSG GPIO drivers"
+	depends on RPMSG
+
+config GPIO_RPMSG
+	tristate "Generic RPMSG GPIO support"
+	depends on OF && REMOTEPROC
+	select GPIOLIB_IRQCHIP
+	default REMOTEPROC
+	help
+	  Say yes here to support the generic GPIO functions over the RPMSG
+	  bus. Currently supported devices: i.MX7ULP, i.MX8ULP, i.MX8x, and
+	  i.MX9x.
+
+	  If unsure, say N.
+
+endmenu
+
 menu "SPI GPIO expanders"
 	depends on SPI_MASTER
 
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index b267598b517d..ee75c0e65b8b 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -157,6 +157,7 @@ obj-$(CONFIG_GPIO_RDC321X)		+= gpio-rdc321x.o
 obj-$(CONFIG_GPIO_REALTEK_OTTO)		+= gpio-realtek-otto.o
 obj-$(CONFIG_GPIO_REG)			+= gpio-reg.o
 obj-$(CONFIG_GPIO_ROCKCHIP)	+= gpio-rockchip.o
+obj-$(CONFIG_GPIO_RPMSG)		+= gpio-rpmsg.o
 obj-$(CONFIG_GPIO_RTD)			+= gpio-rtd.o
 obj-$(CONFIG_ARCH_SA1100)		+= gpio-sa1100.o
 obj-$(CONFIG_GPIO_SAMA5D2_PIOBU)	+= gpio-sama5d2-piobu.o
diff --git a/drivers/gpio/gpio-rpmsg.c b/drivers/gpio/gpio-rpmsg.c
new file mode 100644
index 000000000000..993cde7af2fa
--- /dev/null
+++ b/drivers/gpio/gpio-rpmsg.c
@@ -0,0 +1,573 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright 2026 NXP
+ *
+ * The driver exports a standard gpiochip interface to control
+ * the GPIO controllers via RPMSG on a remote processor.
+ */
+
+#include <linux/completion.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/gpio/driver.h>
+#include <linux/init.h>
+#include <linux/irqdomain.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/remoteproc.h>
+#include <linux/rpmsg.h>
+#include <linux/virtio_gpio.h>
+
+#define MAX_PORT_PER_CHANNEL    10
+#define GPIOS_PER_PORT_DEFAULT	32
+#define RPMSG_TIMEOUT		1000
+
+/* GPIO RPMSG Type */
+#define GPIO_RPMSG_SEND		0
+#define GPIO_RPMSG_REPLY	1
+#define GPIO_RPMSG_NOTIFY	2
+
+struct rpmsg_gpio_packet {
+	u8 type;	/* Message type */
+	u8 cmd;		/* Command code */
+	u8 port_idx;
+	u8 line;
+	u8 val1;
+	u8 val2;
+};
+
+struct rpmsg_gpio_line {
+	u8 irq_shutdown;
+	u8 irq_unmask;
+	u8 irq_mask;
+	u32 irq_wake_enable;
+	u32 irq_type;
+	struct rpmsg_gpio_packet msg;
+};
+
+struct rpmsg_gpio_info {
+	struct rpmsg_device *rpdev;
+	struct rpmsg_gpio_packet *reply_msg;
+	struct completion cmd_complete;
+	struct mutex lock;
+	void **port_store;
+};
+
+struct rpmsg_gpio_port {
+	struct gpio_chip gc;
+	struct rpmsg_gpio_line lines[GPIOS_PER_PORT_DEFAULT];
+	struct rpmsg_gpio_info info;
+	u32 ngpios;
+	u32 idx;
+};
+
+/**
+ * struct rpmsg_drvdata - driver data per channel.
+ * @rproc_name: the name of the remote proc.
+ * @recv_pkt: a pointer to the received packet for protocol fix up.
+ * @channel_devices: an array of the devices related to the rpdev.
+ */
+struct rpdev_drvdata {
+	const char *rproc_name;
+	void *recv_pkt;
+	void *channel_devices[MAX_PORT_PER_CHANNEL];
+};
+
+static int rpmsg_gpio_send_message(struct rpmsg_gpio_port *port,
+				   struct rpmsg_gpio_packet *msg)
+{
+	struct rpmsg_gpio_info *info = &port->info;
+	int ret;
+
+	reinit_completion(&info->cmd_complete);
+
+	ret = rpmsg_send(info->rpdev->ept, msg, sizeof(*msg));
+	if (ret) {
+		dev_err(&info->rpdev->dev, "rpmsg_send failed: %d\n", ret);
+		return ret;
+	}
+
+	ret = wait_for_completion_timeout(&info->cmd_complete,
+					  msecs_to_jiffies(RPMSG_TIMEOUT));
+	if (ret == 0) {
+		dev_err(&info->rpdev->dev, "rpmsg_send timeout!\n");
+		return -ETIMEDOUT;
+	}
+
+	if (info->reply_msg->val1) {
+		dev_err(&info->rpdev->dev, "remote core replies an error: %d!\n",
+			info->reply_msg->val1);
+		return -EINVAL;
+	}
+
+	/* copy the reply message */
+	memcpy(&port->lines[info->reply_msg->line].msg,
+	       info->reply_msg, sizeof(*info->reply_msg));
+
+	return 0;
+}
+
+static struct rpmsg_gpio_packet *
+rpmsg_gpio_msg_init_common(struct rpmsg_gpio_port *port, unsigned int line, u8 cmd)
+{
+	struct rpmsg_gpio_packet *msg = &port->lines[line].msg;
+
+	memset(msg, 0, sizeof(*msg));
+	msg->type = GPIO_RPMSG_SEND;
+	msg->cmd = cmd;
+	msg->port_idx = port->idx;
+	msg->line = line;
+
+	return msg;
+}
+
+static int rpmsg_gpio_get(struct gpio_chip *gc, unsigned int line)
+{
+	struct rpmsg_gpio_port *port = gpiochip_get_data(gc);
+	struct rpmsg_gpio_packet *msg;
+	int ret;
+
+	guard(mutex)(&port->info.lock);
+
+	msg = rpmsg_gpio_msg_init_common(port, line, VIRTIO_GPIO_MSG_GET_VALUE);
+
+	ret = rpmsg_gpio_send_message(port, msg);
+	if (!ret)
+		ret = !!port->lines[line].msg.val2;
+
+	return ret;
+}
+
+static int rpmsg_gpio_get_direction(struct gpio_chip *gc, unsigned int line)
+{
+	struct rpmsg_gpio_port *port = gpiochip_get_data(gc);
+	struct rpmsg_gpio_packet *msg;
+	int ret;
+
+	guard(mutex)(&port->info.lock);
+
+	msg = rpmsg_gpio_msg_init_common(port, line, VIRTIO_GPIO_MSG_GET_DIRECTION);
+
+	ret = rpmsg_gpio_send_message(port, msg);
+	if (ret)
+		return ret;
+
+	switch (port->lines[line].msg.val2) {
+	case VIRTIO_GPIO_DIRECTION_IN:
+		return GPIO_LINE_DIRECTION_IN;
+	case VIRTIO_GPIO_DIRECTION_OUT:
+		return GPIO_LINE_DIRECTION_OUT;
+	default:
+		break;
+	}
+
+	return -EINVAL;
+}
+
+static int rpmsg_gpio_direction_input(struct gpio_chip *gc, unsigned int line)
+{
+	struct rpmsg_gpio_port *port = gpiochip_get_data(gc);
+	struct rpmsg_gpio_packet *msg;
+
+	guard(mutex)(&port->info.lock);
+
+	msg = rpmsg_gpio_msg_init_common(port, line, VIRTIO_GPIO_MSG_SET_DIRECTION);
+	msg->val1 = VIRTIO_GPIO_DIRECTION_IN;
+
+	return rpmsg_gpio_send_message(port, msg);
+}
+
+static int rpmsg_gpio_set(struct gpio_chip *gc, unsigned int line, int val)
+{
+	struct rpmsg_gpio_port *port = gpiochip_get_data(gc);
+	struct rpmsg_gpio_packet *msg;
+
+	guard(mutex)(&port->info.lock);
+
+	msg = rpmsg_gpio_msg_init_common(port, line, VIRTIO_GPIO_MSG_SET_VALUE);
+	msg->val1 = val;
+
+	return rpmsg_gpio_send_message(port, msg);
+}
+
+static int rpmsg_gpio_direction_output(struct gpio_chip *gc, unsigned int line, int val)
+{
+	struct rpmsg_gpio_port *port = gpiochip_get_data(gc);
+	struct rpmsg_gpio_packet *msg;
+	int ret;
+
+	guard(mutex)(&port->info.lock);
+
+	msg = rpmsg_gpio_msg_init_common(port, line, VIRTIO_GPIO_MSG_SET_DIRECTION);
+	msg->val1 = VIRTIO_GPIO_DIRECTION_OUT;
+
+	ret = rpmsg_gpio_send_message(port, msg);
+	if (ret)
+		return ret;
+
+	msg = rpmsg_gpio_msg_init_common(port, line, VIRTIO_GPIO_MSG_SET_VALUE);
+	msg->val1 = val;
+
+	return rpmsg_gpio_send_message(port, msg);
+}
+
+static int gpio_rpmsg_irq_set_type(struct irq_data *d, u32 type)
+{
+	struct rpmsg_gpio_port *port = irq_data_get_irq_chip_data(d);
+	u32 line = d->hwirq;
+
+	switch (type) {
+	case IRQ_TYPE_EDGE_RISING:
+		type = VIRTIO_GPIO_IRQ_TYPE_EDGE_RISING;
+		irq_set_handler_locked(d, handle_simple_irq);
+		break;
+	case IRQ_TYPE_EDGE_FALLING:
+		type = VIRTIO_GPIO_IRQ_TYPE_EDGE_FALLING;
+		irq_set_handler_locked(d, handle_simple_irq);
+		break;
+	case IRQ_TYPE_EDGE_BOTH:
+		type = VIRTIO_GPIO_IRQ_TYPE_EDGE_BOTH;
+		irq_set_handler_locked(d, handle_simple_irq);
+		break;
+	case IRQ_TYPE_LEVEL_LOW:
+		type = VIRTIO_GPIO_IRQ_TYPE_LEVEL_LOW;
+		irq_set_handler_locked(d, handle_level_irq);
+		break;
+	case IRQ_TYPE_LEVEL_HIGH:
+		type = VIRTIO_GPIO_IRQ_TYPE_LEVEL_HIGH;
+		irq_set_handler_locked(d, handle_level_irq);
+		break;
+	default:
+		dev_err(&port->info.rpdev->dev, "unsupported irq type: %u\n", type);
+		return -EINVAL;
+	}
+
+	port->lines[line].irq_type = type;
+
+	return 0;
+}
+
+static int gpio_rpmsg_irq_set_wake(struct irq_data *d, u32 enable)
+{
+	struct rpmsg_gpio_port *port = irq_data_get_irq_chip_data(d);
+	u32 line = d->hwirq;
+
+	port->lines[line].irq_wake_enable = enable;
+
+	return 0;
+}
+
+/*
+ * This unmask/mask function is invoked in two situations:
+ *   - when an interrupt is being set up, and
+ *   - after an interrupt has occurred.
+ *
+ * The GPIO driver does not access hardware registers directly.
+ * Instead, it caches all relevant information locally, and then sends
+ * the accumulated state to the remote system at this stage.
+ */
+static void gpio_rpmsg_unmask_irq(struct irq_data *d)
+{
+	struct rpmsg_gpio_port *port = irq_data_get_irq_chip_data(d);
+	u32 line = d->hwirq;
+
+	port->lines[line].irq_unmask = 1;
+}
+
+static void gpio_rpmsg_mask_irq(struct irq_data *d)
+{
+	struct rpmsg_gpio_port *port = irq_data_get_irq_chip_data(d);
+	u32 line = d->hwirq;
+
+	/*
+	 * When an interrupt occurs, the remote system masks the interrupt
+	 * and then sends a notification to Linux. After Linux processes
+	 * that notification, it sends an RPMsg command back to the remote
+	 * system to unmask the interrupt again.
+	 */
+	port->lines[line].irq_mask = 1;
+}
+
+static void gpio_rpmsg_irq_shutdown(struct irq_data *d)
+{
+	struct rpmsg_gpio_port *port = irq_data_get_irq_chip_data(d);
+	u32 line = d->hwirq;
+
+	port->lines[line].irq_shutdown = 1;
+}
+
+static void gpio_rpmsg_irq_bus_lock(struct irq_data *d)
+{
+	struct rpmsg_gpio_port *port = irq_data_get_irq_chip_data(d);
+
+	mutex_lock(&port->info.lock);
+}
+
+static void gpio_rpmsg_irq_bus_sync_unlock(struct irq_data *d)
+{
+	struct rpmsg_gpio_port *port = irq_data_get_irq_chip_data(d);
+	struct rpmsg_gpio_packet *msg;
+	u32 line = d->hwirq;
+
+	/*
+	 * For mask irq, do nothing here.
+	 * The remote system will mask interrupt after an interrupt occurs,
+	 * and then send a notification to Linux system. After Linux system
+	 * handles the notification, it sends an rpmsg back to the remote
+	 * system to unmask this interrupt again.
+	 */
+	if (port->lines[line].irq_mask && !port->lines[line].irq_unmask) {
+		port->lines[line].irq_mask = 0;
+		mutex_unlock(&port->info.lock);
+		return;
+	}
+
+	msg = rpmsg_gpio_msg_init_common(port, line, VIRTIO_GPIO_MSG_IRQ_TYPE);
+
+	if (port->lines[line].irq_shutdown) {
+		port->lines[line].irq_shutdown = 0;
+		msg->val1 = VIRTIO_GPIO_IRQ_TYPE_NONE;
+		msg->val2 = 0;
+	} else {
+		msg->val1 = port->lines[line].irq_type;
+
+		if (port->lines[line].irq_unmask) {
+			msg->val2 = 0;
+			port->lines[line].irq_unmask = 0;
+		} else /* irq set wake */
+			msg->val2 = port->lines[line].irq_wake_enable;
+	}
+
+	rpmsg_gpio_send_message(port, msg);
+	mutex_unlock(&port->info.lock);
+}
+
+static const struct irq_chip gpio_rpmsg_irq_chip = {
+	.irq_mask = gpio_rpmsg_mask_irq,
+	.irq_unmask = gpio_rpmsg_unmask_irq,
+	.irq_set_wake = gpio_rpmsg_irq_set_wake,
+	.irq_set_type = gpio_rpmsg_irq_set_type,
+	.irq_shutdown = gpio_rpmsg_irq_shutdown,
+	.irq_bus_lock = gpio_rpmsg_irq_bus_lock,
+	.irq_bus_sync_unlock = gpio_rpmsg_irq_bus_sync_unlock,
+	.flags = IRQCHIP_IMMUTABLE,
+};
+
+static void rpmsg_gpio_remove_action(void *data)
+{
+	struct rpmsg_gpio_port *port = data;
+
+	port->info.port_store[port->idx] = NULL;
+}
+
+static int rpmsg_gpiochip_register(struct rpmsg_device *rpdev, struct device_node *np)
+{
+	struct rpdev_drvdata *drvdata = dev_get_drvdata(&rpdev->dev);
+	struct rpmsg_gpio_port *port;
+	struct gpio_irq_chip *girq;
+	struct gpio_chip *gc;
+	int ret;
+
+	port = devm_kzalloc(&rpdev->dev, sizeof(*port), GFP_KERNEL);
+	if (!port)
+		return -ENOMEM;
+
+	ret = of_property_read_u32(np, "reg", &port->idx);
+	if (ret)
+		return ret;
+
+	if (port->idx >= MAX_PORT_PER_CHANNEL)
+		return -EINVAL;
+
+	ret = devm_mutex_init(&rpdev->dev, &port->info.lock);
+	if (ret)
+		return ret;
+
+	ret = of_property_read_u32(np, "ngpios", &port->ngpios);
+	if (ret || port->ngpios > GPIOS_PER_PORT_DEFAULT)
+		port->ngpios = GPIOS_PER_PORT_DEFAULT;
+
+	port->info.reply_msg = devm_kzalloc(&rpdev->dev,
+					    sizeof(*port->info.reply_msg),
+					    GFP_KERNEL);
+	if (!port->info.reply_msg)
+		return -ENOMEM;
+
+	init_completion(&port->info.cmd_complete);
+	port->info.port_store = drvdata->channel_devices;
+	port->info.port_store[port->idx] = port;
+	port->info.rpdev = rpdev;
+
+	gc = &port->gc;
+	gc->owner = THIS_MODULE;
+	gc->parent = &rpdev->dev;
+	gc->fwnode = of_fwnode_handle(np);
+	gc->ngpio = port->ngpios;
+	gc->base = -1;
+	gc->label = devm_kasprintf(&rpdev->dev, GFP_KERNEL, "%s-gpio%d",
+				   drvdata->rproc_name, port->idx);
+
+	gc->direction_input = rpmsg_gpio_direction_input;
+	gc->direction_output = rpmsg_gpio_direction_output;
+	gc->get_direction = rpmsg_gpio_get_direction;
+	gc->get = rpmsg_gpio_get;
+	gc->set = rpmsg_gpio_set;
+
+	girq = &gc->irq;
+	gpio_irq_chip_set_chip(girq, &gpio_rpmsg_irq_chip);
+	girq->parent_handler = NULL;
+	girq->num_parents = 0;
+	girq->parents = NULL;
+	girq->chip->name = devm_kasprintf(&rpdev->dev, GFP_KERNEL, "%s-gpio%d",
+					  drvdata->rproc_name, port->idx);
+
+	ret = devm_add_action_or_reset(&rpdev->dev, rpmsg_gpio_remove_action, port);
+	if (ret)
+		return ret;
+
+	return devm_gpiochip_add_data(&rpdev->dev, gc, port);
+}
+
+static const char *rpmsg_get_rproc_node_name(struct rpmsg_device *rpdev)
+{
+	const char *name = NULL;
+	struct device_node *np;
+	struct rproc *rproc;
+
+	rproc = rproc_get_by_child(&rpdev->dev);
+	if (!rproc)
+		return NULL;
+
+	np = of_node_get(rproc->dev.of_node);
+	if (!np && rproc->dev.parent)
+		np = of_node_get(rproc->dev.parent->of_node);
+
+	if (np) {
+		name = devm_kstrdup(&rpdev->dev, np->name, GFP_KERNEL);
+		of_node_put(np);
+	}
+
+	return name;
+}
+
+static struct device_node *
+rpmsg_get_channel_ofnode(struct rpmsg_device *rpdev, char *chan_name)
+{
+	struct device_node *np_chan = NULL, *np;
+	struct rproc *rproc;
+
+	rproc = rproc_get_by_child(&rpdev->dev);
+	if (!rproc)
+		return NULL;
+
+	np = of_node_get(rproc->dev.of_node);
+	if (!np && rproc->dev.parent)
+		np = of_node_get(rproc->dev.parent->of_node);
+
+	/* The of_node_put() is performed by of_find_node_by_name(). */
+	if (np)
+		np_chan = of_find_node_by_name(np, chan_name);
+
+	return np_chan;
+}
+
+static int rpmsg_gpio_channel_callback(struct rpmsg_device *rpdev, void *data,
+				       int len, void *priv, u32 src)
+{
+	struct rpmsg_gpio_packet *msg = data;
+	struct rpmsg_gpio_port *port = NULL;
+	struct rpdev_drvdata *drvdata;
+
+	drvdata = dev_get_drvdata(&rpdev->dev);
+	if (!msg || !drvdata)
+		return -EINVAL;
+
+	if (msg->port_idx < MAX_PORT_PER_CHANNEL)
+		port = drvdata->channel_devices[msg->port_idx];
+
+	if (!port || msg->line >= port->ngpios) {
+		dev_err(&rpdev->dev, "wrong port index or line number. port:%d line:%d\n",
+			msg->port_idx, msg->line);
+		return -EINVAL;
+	}
+
+	if (msg->type == GPIO_RPMSG_REPLY) {
+		*port->info.reply_msg = *msg;
+		complete(&port->info.cmd_complete);
+	} else if (msg->type == GPIO_RPMSG_NOTIFY) {
+		generic_handle_domain_irq_safe(port->gc.irq.domain, msg->line);
+	} else {
+		dev_err(&rpdev->dev, "wrong command type (0x%x)\n", msg->type);
+	}
+
+	return 0;
+}
+
+static int rpmsg_gpio_channel_probe(struct rpmsg_device *rpdev)
+{
+	struct device *dev = &rpdev->dev;
+	struct rpdev_drvdata *drvdata;
+	struct device_node *np;
+	int ret = -ENODEV;
+
+	if (!dev->of_node) {
+		np = rpmsg_get_channel_ofnode(rpdev, rpdev->id.name);
+		if (np) {
+			dev->of_node = np;
+			set_primary_fwnode(dev, of_fwnode_handle(np));
+		}
+		return -EPROBE_DEFER;
+	}
+
+	drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
+	if (!drvdata)
+		return -ENOMEM;
+
+	drvdata->rproc_name = rpmsg_get_rproc_node_name(rpdev);
+	dev_set_drvdata(dev, drvdata);
+
+	for_each_child_of_node_scoped(dev->of_node, child) {
+		if (!of_device_is_available(child))
+			continue;
+
+		if (!of_match_node(dev->driver->of_match_table, child))
+			continue;
+
+		ret = rpmsg_gpiochip_register(rpdev, child);
+		if (ret < 0)
+			break;
+	}
+
+	return ret;
+}
+
+static const struct of_device_id rpmsg_gpio_dt_ids[] = {
+	{ .compatible = "rpmsg-gpio" },
+	{ /* sentinel */ }
+};
+
+static struct rpmsg_device_id rpmsg_gpio_channel_id_table[] = {
+	{ .name = "rpmsg-io" },
+	{ },
+};
+MODULE_DEVICE_TABLE(rpmsg, rpmsg_gpio_channel_id_table);
+
+static struct rpmsg_driver rpmsg_gpio_channel_client = {
+	.callback	= rpmsg_gpio_channel_callback,
+	.id_table	= rpmsg_gpio_channel_id_table,
+	.probe		= rpmsg_gpio_channel_probe,
+	.drv		= {
+		.name	= KBUILD_MODNAME,
+		.of_match_table = rpmsg_gpio_dt_ids,
+	},
+};
+module_rpmsg_driver(rpmsg_gpio_channel_client);
+
+MODULE_AUTHOR("Shenwei Wang <shenwei.wang@nxp.com>");
+MODULE_DESCRIPTION("generic rpmsg gpio driver");
+MODULE_LICENSE("GPL");
-- 
2.43.0

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

[Padhi, Beleswar]

Hello Shenwei, Greetings,

On 4/23/2026 2:58 AM, Shenwei Wang wrote:
> On an AMP platform, the system may include two processors:


s/two/multiple

> 	- An MCU running an RTOS


s/An MCU/MCUs

> 	- An MPU running Linux
>
> These processors communicate via the RPMSG protocol.
> The driver implements the standard GPIO interface, allowing
> the Linux side to control GPIO controllers which reside in
> the remote processor via RPMSG protocol.
>
> Cc: Bartosz Golaszewski <brgl@bgdev.pl>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com>
> ---
>   drivers/gpio/Kconfig      |  17 ++
>   drivers/gpio/Makefile     |   1 +
>   drivers/gpio/gpio-rpmsg.c | 573 ++++++++++++++++++++++++++++++++++++++
>   3 files changed, 591 insertions(+)
>   create mode 100644 drivers/gpio/gpio-rpmsg.c
>
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index 020e51e30317..4ad299fe3c6f 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -1917,6 +1917,23 @@ config GPIO_SODAVILLE
>   
>   endmenu
>   
> +menu "RPMSG GPIO drivers"
> +	depends on RPMSG
> +
> +config GPIO_RPMSG
> +	tristate "Generic RPMSG GPIO support"
> +	depends on OF && REMOTEPROC
> +	select GPIOLIB_IRQCHIP
> +	default REMOTEPROC
> +	help
> +	  Say yes here to support the generic GPIO functions over the RPMSG
> +	  bus. Currently supported devices: i.MX7ULP, i.MX8ULP, i.MX8x, and
> +	  i.MX9x.
> +
> +	  If unsure, say N.
> +
> +endmenu
> +
>   menu "SPI GPIO expanders"
>   	depends on SPI_MASTER
>   
> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> index b267598b517d..ee75c0e65b8b 100644
> --- a/drivers/gpio/Makefile
> +++ b/drivers/gpio/Makefile
> @@ -157,6 +157,7 @@ obj-$(CONFIG_GPIO_RDC321X)		+= gpio-rdc321x.o
>   obj-$(CONFIG_GPIO_REALTEK_OTTO)		+= gpio-realtek-otto.o
>   obj-$(CONFIG_GPIO_REG)			+= gpio-reg.o
>   obj-$(CONFIG_GPIO_ROCKCHIP)	+= gpio-rockchip.o
> +obj-$(CONFIG_GPIO_RPMSG)		+= gpio-rpmsg.o
>   obj-$(CONFIG_GPIO_RTD)			+= gpio-rtd.o
>   obj-$(CONFIG_ARCH_SA1100)		+= gpio-sa1100.o
>   obj-$(CONFIG_GPIO_SAMA5D2_PIOBU)	+= gpio-sama5d2-piobu.o
> diff --git a/drivers/gpio/gpio-rpmsg.c b/drivers/gpio/gpio-rpmsg.c
> new file mode 100644
> index 000000000000..993cde7af2fa
> --- /dev/null
> +++ b/drivers/gpio/gpio-rpmsg.c
> @@ -0,0 +1,573 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright 2026 NXP
> + *
> + * The driver exports a standard gpiochip interface to control
> + * the GPIO controllers via RPMSG on a remote processor.
> + */
> +
> +#include <linux/completion.h>
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/gpio/driver.h>
> +#include <linux/init.h>
> +#include <linux/irqdomain.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/of_platform.h>
> +#include <linux/platform_device.h>
> +#include <linux/remoteproc.h>
> +#include <linux/rpmsg.h>
> +#include <linux/virtio_gpio.h>
> +
> +#define MAX_PORT_PER_CHANNEL    10
> +#define GPIOS_PER_PORT_DEFAULT	32
> +#define RPMSG_TIMEOUT		1000
> +
> +/* GPIO RPMSG Type */
> +#define GPIO_RPMSG_SEND		0
> +#define GPIO_RPMSG_REPLY	1
> +#define GPIO_RPMSG_NOTIFY	2
> +
> +struct rpmsg_gpio_packet {
> +	u8 type;	/* Message type */
> +	u8 cmd;		/* Command code */
> +	u8 port_idx;
> +	u8 line;
> +	u8 val1;
> +	u8 val2;
> +};


Could you please document the fields in these structs (and the below
ones too)? From the code, it looks like while sending a message from
Linux to Firmware; val1 and val2 are used to describe the values to
set. Whereas while receiving a response, val1 represents a possible
error code, and val2 represents the actual message of get type
queries. If that is so, you might want to change the variable names to
be more descriptive and also use a union.

> +
> +struct rpmsg_gpio_line {
> +	u8 irq_shutdown;
> +	u8 irq_unmask;
> +	u8 irq_mask;
> +	u32 irq_wake_enable;
> +	u32 irq_type;
> +	struct rpmsg_gpio_packet msg;


We don't need to have this field. More info at [0].

> +};
> +
> +struct rpmsg_gpio_info {
> +	struct rpmsg_device *rpdev;
> +	struct rpmsg_gpio_packet *reply_msg;
> +	struct completion cmd_complete;
> +	struct mutex lock;
> +	void **port_store;
> +};
> +
> +struct rpmsg_gpio_port {
> +	struct gpio_chip gc;
> +	struct rpmsg_gpio_line lines[GPIOS_PER_PORT_DEFAULT];
> +	struct rpmsg_gpio_info info;
> +	u32 ngpios;
> +	u32 idx;
> +};
> +
> +/**
> + * struct rpmsg_drvdata - driver data per channel.
> + * @rproc_name: the name of the remote proc.
> + * @recv_pkt: a pointer to the received packet for protocol fix up.
> + * @channel_devices: an array of the devices related to the rpdev.
> + */
> +struct rpdev_drvdata {
> +	const char *rproc_name;
> +	void *recv_pkt;


I don't see any use of this field in the code?

> +	void *channel_devices[MAX_PORT_PER_CHANNEL];


So this is technically a rpmsg endpoint (struct rpmsg_endpoint) without
naming it "endpoint". Every rpmsg endpoint has a reference to its
parent rpmsg channel (struct rpmsg_device) which represents the same
information here. So we should use the framework standard here.

This also allows for dynamic creation and deletion of ports too! (if/when
the firmware supports it)

Which means at port init time, we should make a call to
rpmsg_create_ept() for each port tying the same callback
rpmsg_gpio_channel_callback(). And based on the 'u32 src', we could
identify the appropriate gpio port in the callback.

> +};
> +
> +static int rpmsg_gpio_send_message(struct rpmsg_gpio_port *port,
> +				   struct rpmsg_gpio_packet *msg)
> +{
> +	struct rpmsg_gpio_info *info = &port->info;
> +	int ret;
> +
> +	reinit_completion(&info->cmd_complete);
> +
> +	ret = rpmsg_send(info->rpdev->ept, msg, sizeof(*msg));
> +	if (ret) {
> +		dev_err(&info->rpdev->dev, "rpmsg_send failed: %d\n", ret);
> +		return ret;
> +	}
> +
> +	ret = wait_for_completion_timeout(&info->cmd_complete,
> +					  msecs_to_jiffies(RPMSG_TIMEOUT));
> +	if (ret == 0) {
> +		dev_err(&info->rpdev->dev, "rpmsg_send timeout!\n");
> +		return -ETIMEDOUT;
> +	}
> +
> +	if (info->reply_msg->val1) {
> +		dev_err(&info->rpdev->dev, "remote core replies an error: %d!\n",
> +			info->reply_msg->val1);
> +		return -EINVAL;
> +	}
> +
> +	/* copy the reply message */
> +	memcpy(&port->lines[info->reply_msg->line].msg,
> +	       info->reply_msg, sizeof(*info->reply_msg));


The rpmsg_gpio_port structure already holds a pointer to the reply
message via ->info. We do not need this extra copy. More info at [0].

> +
> +	return 0;
> +}
> +
> +static struct rpmsg_gpio_packet *
> +rpmsg_gpio_msg_init_common(struct rpmsg_gpio_port *port, unsigned int line, u8 cmd)
> +{
> +	struct rpmsg_gpio_packet *msg = &port->lines[line].msg;


[0]: We really don't need to carry the stale message in the line
structure everytime. While sending requests, we should just request a
buffer from kzalloc and use it everytime. As far as response is
concerned, we are holding a lock everytime we are sending any message,
so we are sure the pointer in info->reply_msg would have the response to
only one request that was sent.

> +
> +	memset(msg, 0, sizeof(*msg));


This also means we can get rid of this memset.

> +	msg->type = GPIO_RPMSG_SEND;
> +	msg->cmd = cmd;
> +	msg->port_idx = port->idx;
> +	msg->line = line;
> +
> +	return msg;
> +}
> +
> +static int rpmsg_gpio_get(struct gpio_chip *gc, unsigned int line)
> +{
> +	struct rpmsg_gpio_port *port = gpiochip_get_data(gc);
> +	struct rpmsg_gpio_packet *msg;
> +	int ret;
> +
> +	guard(mutex)(&port->info.lock);
> +
> +	msg = rpmsg_gpio_msg_init_common(port, line, VIRTIO_GPIO_MSG_GET_VALUE);
> +
> +	ret = rpmsg_gpio_send_message(port, msg);
> +	if (!ret)
> +		ret = !!port->lines[line].msg.val2;


Which means here & everywhere else, we could just read the reply message
from !!port->info->reply_msg->val2

> +
> +	return ret;
> +}
> +
> +static int rpmsg_gpio_get_direction(struct gpio_chip *gc, unsigned int line)
> +{
> +	struct rpmsg_gpio_port *port = gpiochip_get_data(gc);
> +	struct rpmsg_gpio_packet *msg;
> +	int ret;
> +
> +	guard(mutex)(&port->info.lock);
> +
> +	msg = rpmsg_gpio_msg_init_common(port, line, VIRTIO_GPIO_MSG_GET_DIRECTION);
> +
> +	ret = rpmsg_gpio_send_message(port, msg);
> +	if (ret)
> +		return ret;
> +
> +	switch (port->lines[line].msg.val2) {
> +	case VIRTIO_GPIO_DIRECTION_IN:
> +		return GPIO_LINE_DIRECTION_IN;
> +	case VIRTIO_GPIO_DIRECTION_OUT:
> +		return GPIO_LINE_DIRECTION_OUT;
> +	default:
> +		break;
> +	}
> +
> +	return -EINVAL;
> +}
> +
> +static int rpmsg_gpio_direction_input(struct gpio_chip *gc, unsigned int line)
> +{
> +	struct rpmsg_gpio_port *port = gpiochip_get_data(gc);
> +	struct rpmsg_gpio_packet *msg;
> +
> +	guard(mutex)(&port->info.lock);
> +
> +	msg = rpmsg_gpio_msg_init_common(port, line, VIRTIO_GPIO_MSG_SET_DIRECTION);
> +	msg->val1 = VIRTIO_GPIO_DIRECTION_IN;
> +
> +	return rpmsg_gpio_send_message(port, msg);
> +}
> +
> +static int rpmsg_gpio_set(struct gpio_chip *gc, unsigned int line, int val)
> +{
> +	struct rpmsg_gpio_port *port = gpiochip_get_data(gc);
> +	struct rpmsg_gpio_packet *msg;
> +
> +	guard(mutex)(&port->info.lock);
> +
> +	msg = rpmsg_gpio_msg_init_common(port, line, VIRTIO_GPIO_MSG_SET_VALUE);
> +	msg->val1 = val;
> +
> +	return rpmsg_gpio_send_message(port, msg);
> +}
> +
> +static int rpmsg_gpio_direction_output(struct gpio_chip *gc, unsigned int line, int val)
> +{
> +	struct rpmsg_gpio_port *port = gpiochip_get_data(gc);
> +	struct rpmsg_gpio_packet *msg;
> +	int ret;
> +
> +	guard(mutex)(&port->info.lock);
> +
> +	msg = rpmsg_gpio_msg_init_common(port, line, VIRTIO_GPIO_MSG_SET_DIRECTION);
> +	msg->val1 = VIRTIO_GPIO_DIRECTION_OUT;
> +
> +	ret = rpmsg_gpio_send_message(port, msg);
> +	if (ret)
> +		return ret;
> +
> +	msg = rpmsg_gpio_msg_init_common(port, line, VIRTIO_GPIO_MSG_SET_VALUE);
> +	msg->val1 = val;
> +
> +	return rpmsg_gpio_send_message(port, msg);
> +}
> +
> +static int gpio_rpmsg_irq_set_type(struct irq_data *d, u32 type)
> +{
> +	struct rpmsg_gpio_port *port = irq_data_get_irq_chip_data(d);
> +	u32 line = d->hwirq;
> +
> +	switch (type) {
> +	case IRQ_TYPE_EDGE_RISING:
> +		type = VIRTIO_GPIO_IRQ_TYPE_EDGE_RISING;
> +		irq_set_handler_locked(d, handle_simple_irq);
> +		break;
> +	case IRQ_TYPE_EDGE_FALLING:
> +		type = VIRTIO_GPIO_IRQ_TYPE_EDGE_FALLING;
> +		irq_set_handler_locked(d, handle_simple_irq);
> +		break;
> +	case IRQ_TYPE_EDGE_BOTH:
> +		type = VIRTIO_GPIO_IRQ_TYPE_EDGE_BOTH;
> +		irq_set_handler_locked(d, handle_simple_irq);
> +		break;
> +	case IRQ_TYPE_LEVEL_LOW:
> +		type = VIRTIO_GPIO_IRQ_TYPE_LEVEL_LOW;
> +		irq_set_handler_locked(d, handle_level_irq);
> +		break;
> +	case IRQ_TYPE_LEVEL_HIGH:
> +		type = VIRTIO_GPIO_IRQ_TYPE_LEVEL_HIGH;
> +		irq_set_handler_locked(d, handle_level_irq);
> +		break;
> +	default:
> +		dev_err(&port->info.rpdev->dev, "unsupported irq type: %u\n", type);
> +		return -EINVAL;
> +	}
> +
> +	port->lines[line].irq_type = type;
> +
> +	return 0;
> +}
> +
> +static int gpio_rpmsg_irq_set_wake(struct irq_data *d, u32 enable)
> +{
> +	struct rpmsg_gpio_port *port = irq_data_get_irq_chip_data(d);
> +	u32 line = d->hwirq;
> +
> +	port->lines[line].irq_wake_enable = enable;
> +
> +	return 0;
> +}
> +
> +/*
> + * This unmask/mask function is invoked in two situations:
> + *   - when an interrupt is being set up, and
> + *   - after an interrupt has occurred.
> + *
> + * The GPIO driver does not access hardware registers directly.
> + * Instead, it caches all relevant information locally, and then sends
> + * the accumulated state to the remote system at this stage.


It is actually sent at the .bus_sync_unlock() stage.

> + */
> +static void gpio_rpmsg_unmask_irq(struct irq_data *d)
> +{
> +	struct rpmsg_gpio_port *port = irq_data_get_irq_chip_data(d);
> +	u32 line = d->hwirq;
> +
> +	port->lines[line].irq_unmask = 1;
> +}
> +
> +static void gpio_rpmsg_mask_irq(struct irq_data *d)
> +{
> +	struct rpmsg_gpio_port *port = irq_data_get_irq_chip_data(d);
> +	u32 line = d->hwirq;
> +
> +	/*
> +	 * When an interrupt occurs, the remote system masks the interrupt
> +	 * and then sends a notification to Linux. After Linux processes
> +	 * that notification, it sends an RPMsg command back to the remote
> +	 * system to unmask the interrupt again.
> +	 */
> +	port->lines[line].irq_mask = 1;
> +}
> +
> +static void gpio_rpmsg_irq_shutdown(struct irq_data *d)
> +{
> +	struct rpmsg_gpio_port *port = irq_data_get_irq_chip_data(d);
> +	u32 line = d->hwirq;
> +
> +	port->lines[line].irq_shutdown = 1;
> +}
> +
> +static void gpio_rpmsg_irq_bus_lock(struct irq_data *d)
> +{
> +	struct rpmsg_gpio_port *port = irq_data_get_irq_chip_data(d);
> +
> +	mutex_lock(&port->info.lock);
> +}
> +
> +static void gpio_rpmsg_irq_bus_sync_unlock(struct irq_data *d)
> +{
> +	struct rpmsg_gpio_port *port = irq_data_get_irq_chip_data(d);
> +	struct rpmsg_gpio_packet *msg;
> +	u32 line = d->hwirq;
> +
> +	/*
> +	 * For mask irq, do nothing here.
> +	 * The remote system will mask interrupt after an interrupt occurs,
> +	 * and then send a notification to Linux system. After Linux system
> +	 * handles the notification, it sends an rpmsg back to the remote
> +	 * system to unmask this interrupt again.
> +	 */
> +	if (port->lines[line].irq_mask && !port->lines[line].irq_unmask) {
> +		port->lines[line].irq_mask = 0;
> +		mutex_unlock(&port->info.lock);
> +		return;
> +	}
> +
> +	msg = rpmsg_gpio_msg_init_common(port, line, VIRTIO_GPIO_MSG_IRQ_TYPE);
> +
> +	if (port->lines[line].irq_shutdown) {
> +		port->lines[line].irq_shutdown = 0;
> +		msg->val1 = VIRTIO_GPIO_IRQ_TYPE_NONE;
> +		msg->val2 = 0;
> +	} else {
> +		msg->val1 = port->lines[line].irq_type;
> +
> +		if (port->lines[line].irq_unmask) {
> +			msg->val2 = 0;
> +			port->lines[line].irq_unmask = 0;
> +		} else /* irq set wake */
> +			msg->val2 = port->lines[line].irq_wake_enable;
> +	}
> +
> +	rpmsg_gpio_send_message(port, msg);
> +	mutex_unlock(&port->info.lock);
> +}
> +
> +static const struct irq_chip gpio_rpmsg_irq_chip = {
> +	.irq_mask = gpio_rpmsg_mask_irq,
> +	.irq_unmask = gpio_rpmsg_unmask_irq,
> +	.irq_set_wake = gpio_rpmsg_irq_set_wake,
> +	.irq_set_type = gpio_rpmsg_irq_set_type,
> +	.irq_shutdown = gpio_rpmsg_irq_shutdown,
> +	.irq_bus_lock = gpio_rpmsg_irq_bus_lock,
> +	.irq_bus_sync_unlock = gpio_rpmsg_irq_bus_sync_unlock,
> +	.flags = IRQCHIP_IMMUTABLE,
> +};
> +
> +static void rpmsg_gpio_remove_action(void *data)
> +{
> +	struct rpmsg_gpio_port *port = data;
> +
> +	port->info.port_store[port->idx] = NULL;
> +}
> +
> +static int rpmsg_gpiochip_register(struct rpmsg_device *rpdev, struct device_node *np)
> +{
> +	struct rpdev_drvdata *drvdata = dev_get_drvdata(&rpdev->dev);
> +	struct rpmsg_gpio_port *port;
> +	struct gpio_irq_chip *girq;
> +	struct gpio_chip *gc;
> +	int ret;
> +
> +	port = devm_kzalloc(&rpdev->dev, sizeof(*port), GFP_KERNEL);
> +	if (!port)
> +		return -ENOMEM;
> +
> +	ret = of_property_read_u32(np, "reg", &port->idx);
> +	if (ret)
> +		return ret;
> +
> +	if (port->idx >= MAX_PORT_PER_CHANNEL)
> +		return -EINVAL;
> +
> +	ret = devm_mutex_init(&rpdev->dev, &port->info.lock);
> +	if (ret)
> +		return ret;
> +
> +	ret = of_property_read_u32(np, "ngpios", &port->ngpios);
> +	if (ret || port->ngpios > GPIOS_PER_PORT_DEFAULT)
> +		port->ngpios = GPIOS_PER_PORT_DEFAULT;
> +
> +	port->info.reply_msg = devm_kzalloc(&rpdev->dev,
> +					    sizeof(*port->info.reply_msg),
> +					    GFP_KERNEL);
> +	if (!port->info.reply_msg)
> +		return -ENOMEM;
> +
> +	init_completion(&port->info.cmd_complete);
> +	port->info.port_store = drvdata->channel_devices;
> +	port->info.port_store[port->idx] = port;
> +	port->info.rpdev = rpdev;
> +
> +	gc = &port->gc;
> +	gc->owner = THIS_MODULE;
> +	gc->parent = &rpdev->dev;
> +	gc->fwnode = of_fwnode_handle(np);
> +	gc->ngpio = port->ngpios;
> +	gc->base = -1;
> +	gc->label = devm_kasprintf(&rpdev->dev, GFP_KERNEL, "%s-gpio%d",
> +				   drvdata->rproc_name, port->idx);
> +
> +	gc->direction_input = rpmsg_gpio_direction_input;
> +	gc->direction_output = rpmsg_gpio_direction_output;
> +	gc->get_direction = rpmsg_gpio_get_direction;
> +	gc->get = rpmsg_gpio_get;
> +	gc->set = rpmsg_gpio_set;
> +
> +	girq = &gc->irq;
> +	gpio_irq_chip_set_chip(girq, &gpio_rpmsg_irq_chip);
> +	girq->parent_handler = NULL;
> +	girq->num_parents = 0;
> +	girq->parents = NULL;
> +	girq->chip->name = devm_kasprintf(&rpdev->dev, GFP_KERNEL, "%s-gpio%d",
> +					  drvdata->rproc_name, port->idx);


We could just re-use gc->label here...

> +
> +	ret = devm_add_action_or_reset(&rpdev->dev, rpmsg_gpio_remove_action, port);
> +	if (ret)
> +		return ret;
> +
> +	return devm_gpiochip_add_data(&rpdev->dev, gc, port);
> +}
> +
> +static const char *rpmsg_get_rproc_node_name(struct rpmsg_device *rpdev)
> +{
> +	const char *name = NULL;
> +	struct device_node *np;
> +	struct rproc *rproc;
> +
> +	rproc = rproc_get_by_child(&rpdev->dev);
> +	if (!rproc)
> +		return NULL;
> +
> +	np = of_node_get(rproc->dev.of_node);
> +	if (!np && rproc->dev.parent)
> +		np = of_node_get(rproc->dev.parent->of_node);
> +
> +	if (np) {
> +		name = devm_kstrdup(&rpdev->dev, np->name, GFP_KERNEL);
> +		of_node_put(np);
> +	}
> +
> +	return name;
> +}
> +
> +static struct device_node *
> +rpmsg_get_channel_ofnode(struct rpmsg_device *rpdev, char *chan_name)
> +{
> +	struct device_node *np_chan = NULL, *np;
> +	struct rproc *rproc;
> +
> +	rproc = rproc_get_by_child(&rpdev->dev);
> +	if (!rproc)
> +		return NULL;
> +
> +	np = of_node_get(rproc->dev.of_node);
> +	if (!np && rproc->dev.parent)
> +		np = of_node_get(rproc->dev.parent->of_node);
> +
> +	/* The of_node_put() is performed by of_find_node_by_name(). */
> +	if (np)
> +		np_chan = of_find_node_by_name(np, chan_name);
> +
> +	return np_chan;
> +}
> +
> +static int rpmsg_gpio_channel_callback(struct rpmsg_device *rpdev, void *data,
> +				       int len, void *priv, u32 src)
> +{
> +	struct rpmsg_gpio_packet *msg = data;
> +	struct rpmsg_gpio_port *port = NULL;
> +	struct rpdev_drvdata *drvdata;
> +
> +	drvdata = dev_get_drvdata(&rpdev->dev);
> +	if (!msg || !drvdata)
> +		return -EINVAL;
> +
> +	if (msg->port_idx < MAX_PORT_PER_CHANNEL)
> +		port = drvdata->channel_devices[msg->port_idx];
> +
> +	if (!port || msg->line >= port->ngpios) {
> +		dev_err(&rpdev->dev, "wrong port index or line number. port:%d line:%d\n",
> +			msg->port_idx, msg->line);
> +		return -EINVAL;
> +	}
> +
> +	if (msg->type == GPIO_RPMSG_REPLY) {
> +		*port->info.reply_msg = *msg;
> +		complete(&port->info.cmd_complete);
> +	} else if (msg->type == GPIO_RPMSG_NOTIFY) {
> +		generic_handle_domain_irq_safe(port->gc.irq.domain, msg->line);
> +	} else {
> +		dev_err(&rpdev->dev, "wrong command type (0x%x)\n", msg->type);
> +	}
> +
> +	return 0;
> +}
> +
> +static int rpmsg_gpio_channel_probe(struct rpmsg_device *rpdev)
> +{
> +	struct device *dev = &rpdev->dev;
> +	struct rpdev_drvdata *drvdata;
> +	struct device_node *np;
> +	int ret = -ENODEV;
> +
> +	if (!dev->of_node) {
> +		np = rpmsg_get_channel_ofnode(rpdev, rpdev->id.name);
> +		if (np) {
> +			dev->of_node = np;
> +			set_primary_fwnode(dev, of_fwnode_handle(np));
> +		}
> +		return -EPROBE_DEFER;


I know this was asked in the v10 version also. But I don't think the
answer is sufficient. Should we not continue the intialization of
drvdata etc if np != 0? Why return a deferred probe, and let the kernel
come back to it again to do the same stuff with extra latency?

We could just do:
if (!np) return -EPROBE_DEFER;
else {everything_else};

> +	}
> +
> +	drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
> +	if (!drvdata)
> +		return -ENOMEM;
> +
> +	drvdata->rproc_name = rpmsg_get_rproc_node_name(rpdev);
> +	dev_set_drvdata(dev, drvdata);
> +
> +	for_each_child_of_node_scoped(dev->of_node, child) {
> +		if (!of_device_is_available(child))
> +			continue;
> +
> +		if (!of_match_node(dev->driver->of_match_table, child))
> +			continue;
> +
> +		ret = rpmsg_gpiochip_register(rpdev, child);
> +		if (ret < 0)
> +			break;


Why break here? If one port initialization fails, it shouldn't impact
the other port right? We should just log this and store the
appropriate value in ret.

Thanks for your time,
Beleswar

> +	}
> +
> +	return ret;
> +}
> +
> +static const struct of_device_id rpmsg_gpio_dt_ids[] = {
> +	{ .compatible = "rpmsg-gpio" },
> +	{ /* sentinel */ }
> +};
> +
> +static struct rpmsg_device_id rpmsg_gpio_channel_id_table[] = {
> +	{ .name = "rpmsg-io" },
> +	{ },
> +};
> +MODULE_DEVICE_TABLE(rpmsg, rpmsg_gpio_channel_id_table);
> +
> +static struct rpmsg_driver rpmsg_gpio_channel_client = {
> +	.callback	= rpmsg_gpio_channel_callback,
> +	.id_table	= rpmsg_gpio_channel_id_table,
> +	.probe		= rpmsg_gpio_channel_probe,
> +	.drv		= {
> +		.name	= KBUILD_MODNAME,
> +		.of_match_table = rpmsg_gpio_dt_ids,
> +	},
> +};
> +module_rpmsg_driver(rpmsg_gpio_channel_client);
> +
> +MODULE_AUTHOR("Shenwei Wang <shenwei.wang@nxp.com>");
> +MODULE_DESCRIPTION("generic rpmsg gpio driver");
> +MODULE_LICENSE("GPL");

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

[Shenwei Wang]

> -----Original Message-----
> From: Padhi, Beleswar <b-padhi@ti.com>
> Sent: Sunday, April 26, 2026 7:44 AM
> To: Shenwei Wang <shenwei.wang@nxp.com>; Linus Walleij
> <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>; Jonathan Corbet
> <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof Kozlowski
> <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn Andersson
> <andersson@kernel.org>; Mathieu Poirier <mathieu.poirier@linaro.org>; Frank Li
> <frank.li@nxp.com>; Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Shuah Khan <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix Kernel Team
> <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; Peng Fan
> <peng.fan@nxp.com>; devicetree@vger.kernel.org; linux-
> remoteproc@vger.kernel.org; imx@lists.linux.dev; linux-arm-
> kernel@lists.infradead.org; dl-linux-imx <linux-imx@nxp.com>; Bartosz
> Golaszewski <brgl@bgdev.pl>; Andrew Lunn <andrew@lunn.ch>
> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
> Hello Shenwei, Greetings,
> 
> On 4/23/2026 2:58 AM, Shenwei Wang wrote:
> > On an AMP platform, the system may include two processors:
> 
> 
> s/two/multiple
> 
> >       - An MCU running an RTOS
> 
> 
> s/An MCU/MCUs
> 
> >       - An MPU running Linux
> >
> > These processors communicate via the RPMSG protocol.
> > The driver implements the standard GPIO interface, allowing the Linux
> > side to control GPIO controllers which reside in the remote processor
> > via RPMSG protocol.
> >
> > Cc: Bartosz Golaszewski <brgl@bgdev.pl>
> > Cc: Andrew Lunn <andrew@lunn.ch>
> > Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com>
> > ---
> >   drivers/gpio/Kconfig      |  17 ++
> >   drivers/gpio/Makefile     |   1 +
> >   drivers/gpio/gpio-rpmsg.c | 573
> ++++++++++++++++++++++++++++++++++++++
> >   3 files changed, 591 insertions(+)
> >   create mode 100644 drivers/gpio/gpio-rpmsg.c
> >
> > diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig index
> > 020e51e30317..4ad299fe3c6f 100644
> > --- a/drivers/gpio/Kconfig
> > +++ b/drivers/gpio/Kconfig
> > @@ -1917,6 +1917,23 @@ config GPIO_SODAVILLE
> >
> >   endmenu
> >
> > +menu "RPMSG GPIO drivers"
> > +     depends on RPMSG
> > +
> > +config GPIO_RPMSG
> > +     tristate "Generic RPMSG GPIO support"
> > +     depends on OF && REMOTEPROC
> > +     select GPIOLIB_IRQCHIP
> > +     default REMOTEPROC
> > +     help
> > +       Say yes here to support the generic GPIO functions over the RPMSG
> > +       bus. Currently supported devices: i.MX7ULP, i.MX8ULP, i.MX8x, and
> > +       i.MX9x.
> > +
> > +       If unsure, say N.
> > +
> > +endmenu
> > +
> >   menu "SPI GPIO expanders"
> >       depends on SPI_MASTER
> >
> > diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile index
> > b267598b517d..ee75c0e65b8b 100644
> > --- a/drivers/gpio/Makefile
> > +++ b/drivers/gpio/Makefile
> > @@ -157,6 +157,7 @@ obj-$(CONFIG_GPIO_RDC321X)                += gpio-
> rdc321x.o
> >   obj-$(CONFIG_GPIO_REALTEK_OTTO)             += gpio-realtek-otto.o
> >   obj-$(CONFIG_GPIO_REG)                      += gpio-reg.o
> >   obj-$(CONFIG_GPIO_ROCKCHIP) += gpio-rockchip.o
> > +obj-$(CONFIG_GPIO_RPMSG)             += gpio-rpmsg.o
> >   obj-$(CONFIG_GPIO_RTD)                      += gpio-rtd.o
> >   obj-$(CONFIG_ARCH_SA1100)           += gpio-sa1100.o
> >   obj-$(CONFIG_GPIO_SAMA5D2_PIOBU)    += gpio-sama5d2-piobu.o
> > diff --git a/drivers/gpio/gpio-rpmsg.c b/drivers/gpio/gpio-rpmsg.c new
> > file mode 100644 index 000000000000..993cde7af2fa
> > --- /dev/null
> > +++ b/drivers/gpio/gpio-rpmsg.c
> > @@ -0,0 +1,573 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright 2026 NXP
> > + *
> > + * The driver exports a standard gpiochip interface to control
> > + * the GPIO controllers via RPMSG on a remote processor.
> > + */
> > +
> > +#include <linux/completion.h>
> > +#include <linux/device.h>
> > +#include <linux/err.h>
> > +#include <linux/gpio/driver.h>
> > +#include <linux/init.h>
> > +#include <linux/irqdomain.h>
> > +#include <linux/mod_devicetable.h>
> > +#include <linux/module.h>
> > +#include <linux/mutex.h>
> > +#include <linux/of.h>
> > +#include <linux/of_device.h>
> > +#include <linux/of_platform.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/remoteproc.h>
> > +#include <linux/rpmsg.h>
> > +#include <linux/virtio_gpio.h>
> > +
> > +#define MAX_PORT_PER_CHANNEL    10
> > +#define GPIOS_PER_PORT_DEFAULT       32
> > +#define RPMSG_TIMEOUT                1000
> > +
> > +/* GPIO RPMSG Type */
> > +#define GPIO_RPMSG_SEND              0
> > +#define GPIO_RPMSG_REPLY     1
> > +#define GPIO_RPMSG_NOTIFY    2
> > +
> > +struct rpmsg_gpio_packet {
> > +     u8 type;        /* Message type */
> > +     u8 cmd;         /* Command code */
> > +     u8 port_idx;
> > +     u8 line;
> > +     u8 val1;
> > +     u8 val2;
> > +};
> 
> 
> Could you please document the fields in these structs (and the below ones too)?
> From the code, it looks like while sending a message from Linux to Firmware; val1
> and val2 are used to describe the values to set. Whereas while receiving a
> response, val1 represents a possible error code, and val2 represents the actual
> message of get type queries. If that is so, you might want to change the variable
> names to be more descriptive and also use a union.
> 

The fields in the two structs are fairly self-explanatory. Do we really need the additional comments?
The previous version of the patch used a union, which was updated to support the fixed_up hooks. 
Now that the fixed_up hooks have been removed, I can revert this back to the union-based implementation.

> > +
> > +struct rpmsg_gpio_line {
> > +     u8 irq_shutdown;
> > +     u8 irq_unmask;
> > +     u8 irq_mask;
> > +     u32 irq_wake_enable;
> > +     u32 irq_type;
> > +     struct rpmsg_gpio_packet msg;
> 
> 
> We don't need to have this field. More info at [0].
> 
> > +};
> > +
> > +struct rpmsg_gpio_info {
> > +     struct rpmsg_device *rpdev;
> > +     struct rpmsg_gpio_packet *reply_msg;
> > +     struct completion cmd_complete;
> > +     struct mutex lock;
> > +     void **port_store;
> > +};
> > +
> > +struct rpmsg_gpio_port {
> > +     struct gpio_chip gc;
> > +     struct rpmsg_gpio_line lines[GPIOS_PER_PORT_DEFAULT];
> > +     struct rpmsg_gpio_info info;
> > +     u32 ngpios;
> > +     u32 idx;
> > +};
> > +
> > +/**
> > + * struct rpmsg_drvdata - driver data per channel.
> > + * @rproc_name: the name of the remote proc.
> > + * @recv_pkt: a pointer to the received packet for protocol fix up.
> > + * @channel_devices: an array of the devices related to the rpdev.
> > + */
> > +struct rpdev_drvdata {
> > +     const char *rproc_name;
> > +     void *recv_pkt;
> 
> 
> I don't see any use of this field in the code?
> 

Will remove it. It was there for fixed_up hooks.

> > +     void *channel_devices[MAX_PORT_PER_CHANNEL];
> 
> 
> So this is technically a rpmsg endpoint (struct rpmsg_endpoint) without naming it
> "endpoint". Every rpmsg endpoint has a reference to its parent rpmsg channel
> (struct rpmsg_device) which represents the same information here. So we should
> use the framework standard here.
> 

Yes, agree to use "endpoint_devices".

> This also allows for dynamic creation and deletion of ports too! (if/when the
> firmware supports it)
> 
> Which means at port init time, we should make a call to
> rpmsg_create_ept() for each port tying the same callback
> rpmsg_gpio_channel_callback(). And based on the 'u32 src', we could identify the
> appropriate gpio port in the callback.
> 
> > +};
> > +
> > +static int rpmsg_gpio_send_message(struct rpmsg_gpio_port *port,
> > +                                struct rpmsg_gpio_packet *msg) {
> > +     struct rpmsg_gpio_info *info = &port->info;
> > +     int ret;
> > +
> > +     reinit_completion(&info->cmd_complete);
> > +
> > +     ret = rpmsg_send(info->rpdev->ept, msg, sizeof(*msg));
> > +     if (ret) {
> > +             dev_err(&info->rpdev->dev, "rpmsg_send failed: %d\n", ret);
> > +             return ret;
> > +     }
> > +
> > +     ret = wait_for_completion_timeout(&info->cmd_complete,
> > +                                       msecs_to_jiffies(RPMSG_TIMEOUT));
> > +     if (ret == 0) {
> > +             dev_err(&info->rpdev->dev, "rpmsg_send timeout!\n");
> > +             return -ETIMEDOUT;
> > +     }
> > +
> > +     if (info->reply_msg->val1) {
> > +             dev_err(&info->rpdev->dev, "remote core replies an error: %d!\n",
> > +                     info->reply_msg->val1);
> > +             return -EINVAL;
> > +     }
> > +
> > +     /* copy the reply message */
> > +     memcpy(&port->lines[info->reply_msg->line].msg,
> > +            info->reply_msg, sizeof(*info->reply_msg));
> 
> 
> The rpmsg_gpio_port structure already holds a pointer to the reply message via -
> >info. We do not need this extra copy. More info at [0].
> 
> > +
> > +     return 0;
> > +}
> > +
> > +static struct rpmsg_gpio_packet *
> > +rpmsg_gpio_msg_init_common(struct rpmsg_gpio_port *port, unsigned int
> > +line, u8 cmd) {
> > +     struct rpmsg_gpio_packet *msg = &port->lines[line].msg;
> 
> 
> [0]: We really don't need to carry the stale message in the line structure
> everytime. While sending requests, we should just request a buffer from kzalloc
> and use it everytime. As far as response is concerned, we are holding a lock
> everytime we are sending any message, so we are sure the pointer in info-
> >reply_msg would have the response to only one request that was sent.
> 

looks reasonable. 

> > +
> > +     memset(msg, 0, sizeof(*msg));
> 
> 
> This also means we can get rid of this memset.
> 
> > +     msg->type = GPIO_RPMSG_SEND;
> > +     msg->cmd = cmd;
> > +     msg->port_idx = port->idx;
> > +     msg->line = line;
> > +
> > +     return msg;
> > +}
> > +
> > +static int rpmsg_gpio_get(struct gpio_chip *gc, unsigned int line) {
> > +     struct rpmsg_gpio_port *port = gpiochip_get_data(gc);
> > +     struct rpmsg_gpio_packet *msg;
> > +     int ret;
> > +
> > +     guard(mutex)(&port->info.lock);
> > +
> > +     msg = rpmsg_gpio_msg_init_common(port, line,
> > + VIRTIO_GPIO_MSG_GET_VALUE);
> > +
> > +     ret = rpmsg_gpio_send_message(port, msg);
> > +     if (!ret)
> > +             ret = !!port->lines[line].msg.val2;
> 
> 
> Which means here & everywhere else, we could just read the reply message
> from !!port->info->reply_msg->val2
> 
> > +
> > +     return ret;
> > +}
> > +
> > +static int rpmsg_gpio_get_direction(struct gpio_chip *gc, unsigned
> > +int line) {
> > +     struct rpmsg_gpio_port *port = gpiochip_get_data(gc);
> > +     struct rpmsg_gpio_packet *msg;
> > +     int ret;
> > +
> > +     guard(mutex)(&port->info.lock);
> > +
> > +     msg = rpmsg_gpio_msg_init_common(port, line,
> > + VIRTIO_GPIO_MSG_GET_DIRECTION);
> > +
> > +     ret = rpmsg_gpio_send_message(port, msg);
> > +     if (ret)
> > +             return ret;
> > +
> > +     switch (port->lines[line].msg.val2) {
> > +     case VIRTIO_GPIO_DIRECTION_IN:
> > +             return GPIO_LINE_DIRECTION_IN;
> > +     case VIRTIO_GPIO_DIRECTION_OUT:
> > +             return GPIO_LINE_DIRECTION_OUT;
> > +     default:
> > +             break;
> > +     }
> > +
> > +     return -EINVAL;
> > +}
> > +
> > +static int rpmsg_gpio_direction_input(struct gpio_chip *gc, unsigned
> > +int line) {
> > +     struct rpmsg_gpio_port *port = gpiochip_get_data(gc);
> > +     struct rpmsg_gpio_packet *msg;
> > +
> > +     guard(mutex)(&port->info.lock);
> > +
> > +     msg = rpmsg_gpio_msg_init_common(port, line,
> VIRTIO_GPIO_MSG_SET_DIRECTION);
> > +     msg->val1 = VIRTIO_GPIO_DIRECTION_IN;
> > +
> > +     return rpmsg_gpio_send_message(port, msg); }
> > +
> > +static int rpmsg_gpio_set(struct gpio_chip *gc, unsigned int line,
> > +int val) {
> > +     struct rpmsg_gpio_port *port = gpiochip_get_data(gc);
> > +     struct rpmsg_gpio_packet *msg;
> > +
> > +     guard(mutex)(&port->info.lock);
> > +
> > +     msg = rpmsg_gpio_msg_init_common(port, line,
> VIRTIO_GPIO_MSG_SET_VALUE);
> > +     msg->val1 = val;
> > +
> > +     return rpmsg_gpio_send_message(port, msg); }
> > +
> > +static int rpmsg_gpio_direction_output(struct gpio_chip *gc, unsigned
> > +int line, int val) {
> > +     struct rpmsg_gpio_port *port = gpiochip_get_data(gc);
> > +     struct rpmsg_gpio_packet *msg;
> > +     int ret;
> > +
> > +     guard(mutex)(&port->info.lock);
> > +
> > +     msg = rpmsg_gpio_msg_init_common(port, line,
> VIRTIO_GPIO_MSG_SET_DIRECTION);
> > +     msg->val1 = VIRTIO_GPIO_DIRECTION_OUT;
> > +
> > +     ret = rpmsg_gpio_send_message(port, msg);
> > +     if (ret)
> > +             return ret;
> > +
> > +     msg = rpmsg_gpio_msg_init_common(port, line,
> VIRTIO_GPIO_MSG_SET_VALUE);
> > +     msg->val1 = val;
> > +
> > +     return rpmsg_gpio_send_message(port, msg); }
> > +
> > +static int gpio_rpmsg_irq_set_type(struct irq_data *d, u32 type) {
> > +     struct rpmsg_gpio_port *port = irq_data_get_irq_chip_data(d);
> > +     u32 line = d->hwirq;
> > +
> > +     switch (type) {
> > +     case IRQ_TYPE_EDGE_RISING:
> > +             type = VIRTIO_GPIO_IRQ_TYPE_EDGE_RISING;
> > +             irq_set_handler_locked(d, handle_simple_irq);
> > +             break;
> > +     case IRQ_TYPE_EDGE_FALLING:
> > +             type = VIRTIO_GPIO_IRQ_TYPE_EDGE_FALLING;
> > +             irq_set_handler_locked(d, handle_simple_irq);
> > +             break;
> > +     case IRQ_TYPE_EDGE_BOTH:
> > +             type = VIRTIO_GPIO_IRQ_TYPE_EDGE_BOTH;
> > +             irq_set_handler_locked(d, handle_simple_irq);
> > +             break;
> > +     case IRQ_TYPE_LEVEL_LOW:
> > +             type = VIRTIO_GPIO_IRQ_TYPE_LEVEL_LOW;
> > +             irq_set_handler_locked(d, handle_level_irq);
> > +             break;
> > +     case IRQ_TYPE_LEVEL_HIGH:
> > +             type = VIRTIO_GPIO_IRQ_TYPE_LEVEL_HIGH;
> > +             irq_set_handler_locked(d, handle_level_irq);
> > +             break;
> > +     default:
> > +             dev_err(&port->info.rpdev->dev, "unsupported irq type: %u\n", type);
> > +             return -EINVAL;
> > +     }
> > +
> > +     port->lines[line].irq_type = type;
> > +
> > +     return 0;
> > +}
> > +
> > +static int gpio_rpmsg_irq_set_wake(struct irq_data *d, u32 enable) {
> > +     struct rpmsg_gpio_port *port = irq_data_get_irq_chip_data(d);
> > +     u32 line = d->hwirq;
> > +
> > +     port->lines[line].irq_wake_enable = enable;
> > +
> > +     return 0;
> > +}
> > +
> > +/*
> > + * This unmask/mask function is invoked in two situations:
> > + *   - when an interrupt is being set up, and
> > + *   - after an interrupt has occurred.
> > + *
> > + * The GPIO driver does not access hardware registers directly.
> > + * Instead, it caches all relevant information locally, and then
> > +sends
> > + * the accumulated state to the remote system at this stage.
> 
> 
> It is actually sent at the .bus_sync_unlock() stage.
> 
> > + */
> > +static void gpio_rpmsg_unmask_irq(struct irq_data *d) {
> > +     struct rpmsg_gpio_port *port = irq_data_get_irq_chip_data(d);
> > +     u32 line = d->hwirq;
> > +
> > +     port->lines[line].irq_unmask = 1; }
> > +
> > +static void gpio_rpmsg_mask_irq(struct irq_data *d) {
> > +     struct rpmsg_gpio_port *port = irq_data_get_irq_chip_data(d);
> > +     u32 line = d->hwirq;
> > +
> > +     /*
> > +      * When an interrupt occurs, the remote system masks the interrupt
> > +      * and then sends a notification to Linux. After Linux processes
> > +      * that notification, it sends an RPMsg command back to the remote
> > +      * system to unmask the interrupt again.
> > +      */
> > +     port->lines[line].irq_mask = 1;
> > +}
> > +
> > +static void gpio_rpmsg_irq_shutdown(struct irq_data *d) {
> > +     struct rpmsg_gpio_port *port = irq_data_get_irq_chip_data(d);
> > +     u32 line = d->hwirq;
> > +
> > +     port->lines[line].irq_shutdown = 1; }
> > +
> > +static void gpio_rpmsg_irq_bus_lock(struct irq_data *d) {
> > +     struct rpmsg_gpio_port *port = irq_data_get_irq_chip_data(d);
> > +
> > +     mutex_lock(&port->info.lock);
> > +}
> > +
> > +static void gpio_rpmsg_irq_bus_sync_unlock(struct irq_data *d) {
> > +     struct rpmsg_gpio_port *port = irq_data_get_irq_chip_data(d);
> > +     struct rpmsg_gpio_packet *msg;
> > +     u32 line = d->hwirq;
> > +
> > +     /*
> > +      * For mask irq, do nothing here.
> > +      * The remote system will mask interrupt after an interrupt occurs,
> > +      * and then send a notification to Linux system. After Linux system
> > +      * handles the notification, it sends an rpmsg back to the remote
> > +      * system to unmask this interrupt again.
> > +      */
> > +     if (port->lines[line].irq_mask && !port->lines[line].irq_unmask) {
> > +             port->lines[line].irq_mask = 0;
> > +             mutex_unlock(&port->info.lock);
> > +             return;
> > +     }
> > +
> > +     msg = rpmsg_gpio_msg_init_common(port, line,
> > + VIRTIO_GPIO_MSG_IRQ_TYPE);
> > +
> > +     if (port->lines[line].irq_shutdown) {
> > +             port->lines[line].irq_shutdown = 0;
> > +             msg->val1 = VIRTIO_GPIO_IRQ_TYPE_NONE;
> > +             msg->val2 = 0;
> > +     } else {
> > +             msg->val1 = port->lines[line].irq_type;
> > +
> > +             if (port->lines[line].irq_unmask) {
> > +                     msg->val2 = 0;
> > +                     port->lines[line].irq_unmask = 0;
> > +             } else /* irq set wake */
> > +                     msg->val2 = port->lines[line].irq_wake_enable;
> > +     }
> > +
> > +     rpmsg_gpio_send_message(port, msg);
> > +     mutex_unlock(&port->info.lock);
> > +}
> > +
> > +static const struct irq_chip gpio_rpmsg_irq_chip = {
> > +     .irq_mask = gpio_rpmsg_mask_irq,
> > +     .irq_unmask = gpio_rpmsg_unmask_irq,
> > +     .irq_set_wake = gpio_rpmsg_irq_set_wake,
> > +     .irq_set_type = gpio_rpmsg_irq_set_type,
> > +     .irq_shutdown = gpio_rpmsg_irq_shutdown,
> > +     .irq_bus_lock = gpio_rpmsg_irq_bus_lock,
> > +     .irq_bus_sync_unlock = gpio_rpmsg_irq_bus_sync_unlock,
> > +     .flags = IRQCHIP_IMMUTABLE,
> > +};
> > +
> > +static void rpmsg_gpio_remove_action(void *data) {
> > +     struct rpmsg_gpio_port *port = data;
> > +
> > +     port->info.port_store[port->idx] = NULL; }
> > +
> > +static int rpmsg_gpiochip_register(struct rpmsg_device *rpdev, struct
> > +device_node *np) {
> > +     struct rpdev_drvdata *drvdata = dev_get_drvdata(&rpdev->dev);
> > +     struct rpmsg_gpio_port *port;
> > +     struct gpio_irq_chip *girq;
> > +     struct gpio_chip *gc;
> > +     int ret;
> > +
> > +     port = devm_kzalloc(&rpdev->dev, sizeof(*port), GFP_KERNEL);
> > +     if (!port)
> > +             return -ENOMEM;
> > +
> > +     ret = of_property_read_u32(np, "reg", &port->idx);
> > +     if (ret)
> > +             return ret;
> > +
> > +     if (port->idx >= MAX_PORT_PER_CHANNEL)
> > +             return -EINVAL;
> > +
> > +     ret = devm_mutex_init(&rpdev->dev, &port->info.lock);
> > +     if (ret)
> > +             return ret;
> > +
> > +     ret = of_property_read_u32(np, "ngpios", &port->ngpios);
> > +     if (ret || port->ngpios > GPIOS_PER_PORT_DEFAULT)
> > +             port->ngpios = GPIOS_PER_PORT_DEFAULT;
> > +
> > +     port->info.reply_msg = devm_kzalloc(&rpdev->dev,
> > +                                         sizeof(*port->info.reply_msg),
> > +                                         GFP_KERNEL);
> > +     if (!port->info.reply_msg)
> > +             return -ENOMEM;
> > +
> > +     init_completion(&port->info.cmd_complete);
> > +     port->info.port_store = drvdata->channel_devices;
> > +     port->info.port_store[port->idx] = port;
> > +     port->info.rpdev = rpdev;
> > +
> > +     gc = &port->gc;
> > +     gc->owner = THIS_MODULE;
> > +     gc->parent = &rpdev->dev;
> > +     gc->fwnode = of_fwnode_handle(np);
> > +     gc->ngpio = port->ngpios;
> > +     gc->base = -1;
> > +     gc->label = devm_kasprintf(&rpdev->dev, GFP_KERNEL, "%s-gpio%d",
> > +                                drvdata->rproc_name, port->idx);
> > +
> > +     gc->direction_input = rpmsg_gpio_direction_input;
> > +     gc->direction_output = rpmsg_gpio_direction_output;
> > +     gc->get_direction = rpmsg_gpio_get_direction;
> > +     gc->get = rpmsg_gpio_get;
> > +     gc->set = rpmsg_gpio_set;
> > +
> > +     girq = &gc->irq;
> > +     gpio_irq_chip_set_chip(girq, &gpio_rpmsg_irq_chip);
> > +     girq->parent_handler = NULL;
> > +     girq->num_parents = 0;
> > +     girq->parents = NULL;
> > +     girq->chip->name = devm_kasprintf(&rpdev->dev, GFP_KERNEL, "%s-
> gpio%d",
> > +                                       drvdata->rproc_name,
> > + port->idx);
> 
> 
> We could just re-use gc->label here...

We also want to include the remoteproc name (for example, remoteproc-cm33-gpio0), rather than just gpio0.

> 
> > +
> > +     ret = devm_add_action_or_reset(&rpdev->dev,
> rpmsg_gpio_remove_action, port);
> > +     if (ret)
> > +             return ret;
> > +
> > +     return devm_gpiochip_add_data(&rpdev->dev, gc, port); }
> > +
> > +static const char *rpmsg_get_rproc_node_name(struct rpmsg_device
> > +*rpdev) {
> > +     const char *name = NULL;
> > +     struct device_node *np;
> > +     struct rproc *rproc;
> > +
> > +     rproc = rproc_get_by_child(&rpdev->dev);
> > +     if (!rproc)
> > +             return NULL;
> > +
> > +     np = of_node_get(rproc->dev.of_node);
> > +     if (!np && rproc->dev.parent)
> > +             np = of_node_get(rproc->dev.parent->of_node);
> > +
> > +     if (np) {
> > +             name = devm_kstrdup(&rpdev->dev, np->name, GFP_KERNEL);
> > +             of_node_put(np);
> > +     }
> > +
> > +     return name;
> > +}
> > +
> > +static struct device_node *
> > +rpmsg_get_channel_ofnode(struct rpmsg_device *rpdev, char *chan_name)
> > +{
> > +     struct device_node *np_chan = NULL, *np;
> > +     struct rproc *rproc;
> > +
> > +     rproc = rproc_get_by_child(&rpdev->dev);
> > +     if (!rproc)
> > +             return NULL;
> > +
> > +     np = of_node_get(rproc->dev.of_node);
> > +     if (!np && rproc->dev.parent)
> > +             np = of_node_get(rproc->dev.parent->of_node);
> > +
> > +     /* The of_node_put() is performed by of_find_node_by_name(). */
> > +     if (np)
> > +             np_chan = of_find_node_by_name(np, chan_name);
> > +
> > +     return np_chan;
> > +}
> > +
> > +static int rpmsg_gpio_channel_callback(struct rpmsg_device *rpdev, void
> *data,
> > +                                    int len, void *priv, u32 src) {
> > +     struct rpmsg_gpio_packet *msg = data;
> > +     struct rpmsg_gpio_port *port = NULL;
> > +     struct rpdev_drvdata *drvdata;
> > +
> > +     drvdata = dev_get_drvdata(&rpdev->dev);
> > +     if (!msg || !drvdata)
> > +             return -EINVAL;
> > +
> > +     if (msg->port_idx < MAX_PORT_PER_CHANNEL)
> > +             port = drvdata->channel_devices[msg->port_idx];
> > +
> > +     if (!port || msg->line >= port->ngpios) {
> > +             dev_err(&rpdev->dev, "wrong port index or line number. port:%d
> line:%d\n",
> > +                     msg->port_idx, msg->line);
> > +             return -EINVAL;
> > +     }
> > +
> > +     if (msg->type == GPIO_RPMSG_REPLY) {
> > +             *port->info.reply_msg = *msg;
> > +             complete(&port->info.cmd_complete);
> > +     } else if (msg->type == GPIO_RPMSG_NOTIFY) {
> > +             generic_handle_domain_irq_safe(port->gc.irq.domain, msg->line);
> > +     } else {
> > +             dev_err(&rpdev->dev, "wrong command type (0x%x)\n", msg->type);
> > +     }
> > +
> > +     return 0;
> > +}
> > +
> > +static int rpmsg_gpio_channel_probe(struct rpmsg_device *rpdev) {
> > +     struct device *dev = &rpdev->dev;
> > +     struct rpdev_drvdata *drvdata;
> > +     struct device_node *np;
> > +     int ret = -ENODEV;
> > +
> > +     if (!dev->of_node) {
> > +             np = rpmsg_get_channel_ofnode(rpdev, rpdev->id.name);
> > +             if (np) {
> > +                     dev->of_node = np;
> > +                     set_primary_fwnode(dev, of_fwnode_handle(np));
> > +             }
> > +             return -EPROBE_DEFER;
> 
> 
> I know this was asked in the v10 version also. But I don't think the answer is
> sufficient. Should we not continue the intialization of drvdata etc if np != 0? Why
> return a deferred probe, and let the kernel come back to it again to do the same
> stuff with extra latency?
> 
> We could just do:
> if (!np) return -EPROBE_DEFER;
> else {everything_else};
> 

After configuring dev->of_node, it would be better to restart the driver probe process. 
This ensures that all required resources, such as pinctrl, clocks, and power domains, are 
properly set up if they are specified in the device node, before the probe function is invoked.

Thanks,
Shenwei

> > +     }
> > +
> > +     drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
> > +     if (!drvdata)
> > +             return -ENOMEM;
> > +
> > +     drvdata->rproc_name = rpmsg_get_rproc_node_name(rpdev);
> > +     dev_set_drvdata(dev, drvdata);
> > +
> > +     for_each_child_of_node_scoped(dev->of_node, child) {
> > +             if (!of_device_is_available(child))
> > +                     continue;
> > +
> > +             if (!of_match_node(dev->driver->of_match_table, child))
> > +                     continue;
> > +
> > +             ret = rpmsg_gpiochip_register(rpdev, child);
> > +             if (ret < 0)
> > +                     break;
> 
> 
> Why break here? If one port initialization fails, it shouldn't impact the other port
> right? We should just log this and store the appropriate value in ret.
> 
> Thanks for your time,
> Beleswar
> 
> > +     }
> > +
> > +     return ret;
> > +}
> > +
> > +static const struct of_device_id rpmsg_gpio_dt_ids[] = {
> > +     { .compatible = "rpmsg-gpio" },
> > +     { /* sentinel */ }
> > +};
> > +
> > +static struct rpmsg_device_id rpmsg_gpio_channel_id_table[] = {
> > +     { .name = "rpmsg-io" },
> > +     { },
> > +};
> > +MODULE_DEVICE_TABLE(rpmsg, rpmsg_gpio_channel_id_table);
> > +
> > +static struct rpmsg_driver rpmsg_gpio_channel_client = {
> > +     .callback       = rpmsg_gpio_channel_callback,
> > +     .id_table       = rpmsg_gpio_channel_id_table,
> > +     .probe          = rpmsg_gpio_channel_probe,
> > +     .drv            = {
> > +             .name   = KBUILD_MODNAME,
> > +             .of_match_table = rpmsg_gpio_dt_ids,
> > +     },
> > +};
> > +module_rpmsg_driver(rpmsg_gpio_channel_client);
> > +
> > +MODULE_AUTHOR("Shenwei Wang <shenwei.wang@nxp.com>");
> > +MODULE_DESCRIPTION("generic rpmsg gpio driver");
> > +MODULE_LICENSE("GPL");

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

[Andrew Lunn]

> > > +struct rpmsg_gpio_packet {
> > > +     u8 type;        /* Message type */
> > > +     u8 cmd;         /* Command code */
> > > +     u8 port_idx;
> > > +     u8 line;
> > > +     u8 val1;
> > > +     u8 val2;
> > > +};
> > 
> > 
> > Could you please document the fields in these structs (and the below ones too)?
> > From the code, it looks like while sending a message from Linux to Firmware; val1
> > and val2 are used to describe the values to set. Whereas while receiving a
> > response, val1 represents a possible error code, and val2 represents the actual
> > message of get type queries. If that is so, you might want to change the variable
> > names to be more descriptive and also use a union.
> > 
> 
> The fields in the two structs are fairly self-explanatory. Do we really need the additional comments?
> The previous version of the patch used a union, which was updated to support the fixed_up hooks. 
> Now that the fixed_up hooks have been removed, I can revert this back to the union-based implementation.

I thought you had already adopted the virtio message format?


/* Possible values of the status field */
#define VIRTIO_GPIO_STATUS_OK			0x0
#define VIRTIO_GPIO_STATUS_ERR			0x1

struct virtio_gpio_response {
	__u8 status;
	__u8 value;
};

Seems pretty obvious what status means. value depends on the request,
get_direction actually uses it, and it can be one of

#define VIRTIO_GPIO_DIRECTION_NONE		0x00
#define VIRTIO_GPIO_DIRECTION_OUT		0x01
#define VIRTIO_GPIO_DIRECTION_IN		0x02

and gpio_get uses it as a bool for the state of the GPIO.

Why do we need all the complexity for val1, val2, etc?

  Andrew

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

[Shenwei Wang]

> -----Original Message-----
> From: Andrew Lunn <andrew@lunn.ch>
> Sent: Monday, April 27, 2026 3:28 PM
> To: Shenwei Wang <shenwei.wang@nxp.com>
> Cc: Padhi, Beleswar <b-padhi@ti.com>; Linus Walleij <linusw@kernel.org>;
> Bartosz Golaszewski <brgl@kernel.org>; Jonathan Corbet <corbet@lwn.net>;
> Rob Herring <robh@kernel.org>; Krzysztof Kozlowski <krzk+dt@kernel.org>;
> Conor Dooley <conor+dt@kernel.org>; Bjorn Andersson
> <andersson@kernel.org>; Mathieu Poirier <mathieu.poirier@linaro.org>; Frank Li
> <frank.li@nxp.com>; Sascha Hauer <s.hauer@pengutronix.de>; Shuah Khan
> <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix Kernel Team
> <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; Peng Fan
> <peng.fan@nxp.com>; devicetree@vger.kernel.org; linux-
> remoteproc@vger.kernel.org; imx@lists.linux.dev; linux-arm-
> kernel@lists.infradead.org; dl-linux-imx <linux-imx@nxp.com>; Bartosz
> Golaszewski <brgl@bgdev.pl>
> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
> > > > +struct rpmsg_gpio_packet {
> > > > +     u8 type;        /* Message type */
> > > > +     u8 cmd;         /* Command code */
> > > > +     u8 port_idx;
> > > > +     u8 line;
> > > > +     u8 val1;
> > > > +     u8 val2;
> > > > +};
> > >
> > >
> > > Could you please document the fields in these structs (and the below ones
> too)?
> > > From the code, it looks like while sending a message from Linux to
> > > Firmware; val1 and val2 are used to describe the values to set.
> > > Whereas while receiving a response, val1 represents a possible error
> > > code, and val2 represents the actual message of get type queries. If
> > > that is so, you might want to change the variable names to be more
> descriptive and also use a union.
> > >
> >
> > The fields in the two structs are fairly self-explanatory. Do we really need the
> additional comments?
> > The previous version of the patch used a union, which was updated to support
> the fixed_up hooks.
> > Now that the fixed_up hooks have been removed, I can revert this back to the
> union-based implementation.
> 
> I thought you had already adopted the virtio message format?
> 
> 
> /* Possible values of the status field */
> #define VIRTIO_GPIO_STATUS_OK                   0x0
> #define VIRTIO_GPIO_STATUS_ERR                  0x1
> 
> struct virtio_gpio_response {
>         __u8 status;
>         __u8 value;
> };
> 
> Seems pretty obvious what status means. value depends on the request,
> get_direction actually uses it, and it can be one of
> 
> #define VIRTIO_GPIO_DIRECTION_NONE              0x00
> #define VIRTIO_GPIO_DIRECTION_OUT               0x01
> #define VIRTIO_GPIO_DIRECTION_IN                0x02
> 
> and gpio_get uses it as a bool for the state of the GPIO.
> 
> Why do we need all the complexity for val1, val2, etc?
> 

It is the same message format. Please see the message definition (GET_DIRECTION) below:

+GET_DIRECTION (Cmd=2)
+~~~~~~~~~~~~~~~~~~~~~
+
+**Request:**
+
+.. code-block:: none
+
+   +-----+-----+-----+-----+-----+----+
+   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
+   | 0   | 2   |port |line | 0   | 0  |
+   +-----+-----+-----+-----+-----+----+
+
+**Reply:**
+
+.. code-block:: none
+
+   +-----+-----+-----+-----+-----+----+
+   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
+   | 1   | 2   |port |line | err | dir|
+   +-----+-----+-----+-----+-----+----+
+
+- **err**: See above for definitions.
+
+- **dir**: Direction.
+
+  - 0: None
+  - 1: Output
+  - 2: Input
+

Shenwei

>   Andrew

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

[Andrew Lunn]

> > struct virtio_gpio_response {
> >         __u8 status;
> >         __u8 value;
> > };

> It is the same message format. Please see the message definition (GET_DIRECTION) below:

> +   +-----+-----+-----+-----+-----+----+
> +   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
> +   | 1   | 2   |port |line | err | dir|
> +   +-----+-----+-----+-----+-----+----+

Sorry, but i don't see how two u8 vs six u8 are the same message
format.

       Andrew

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

[Shenwei Wang]

> -----Original Message-----
> From: Andrew Lunn <andrew@lunn.ch>
> Sent: Monday, April 27, 2026 3:49 PM
> To: Shenwei Wang <shenwei.wang@nxp.com>
> Cc: Padhi, Beleswar <b-padhi@ti.com>; Linus Walleij <linusw@kernel.org>;
> Bartosz Golaszewski <brgl@kernel.org>; Jonathan Corbet <corbet@lwn.net>;
> Rob Herring <robh@kernel.org>; Krzysztof Kozlowski <krzk+dt@kernel.org>;
> Conor Dooley <conor+dt@kernel.org>; Bjorn Andersson
> <andersson@kernel.org>; Mathieu Poirier <mathieu.poirier@linaro.org>; Frank Li
> <frank.li@nxp.com>; Sascha Hauer <s.hauer@pengutronix.de>; Shuah Khan
> <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix Kernel Team
> <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; Peng Fan
> <peng.fan@nxp.com>; devicetree@vger.kernel.org; linux-
> remoteproc@vger.kernel.org; imx@lists.linux.dev; linux-arm-
> kernel@lists.infradead.org; dl-linux-imx <linux-imx@nxp.com>; Bartosz
> Golaszewski <brgl@bgdev.pl>
> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
> > > struct virtio_gpio_response {
> > >         __u8 status;
> > >         __u8 value;
> > > };
> 
> > It is the same message format. Please see the message definition
> (GET_DIRECTION) below:
> 
> > +   +-----+-----+-----+-----+-----+----+
> > +   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
> > +   | 1   | 2   |port |line | err | dir|
> > +   +-----+-----+-----+-----+-----+----+
> 
> Sorry, but i don't see how two u8 vs six u8 are the same message format.
> 

Some changes to the message format are necessary.

Virtio uses two communication channels (virtqueues): one for requests and replies, and a second one for events. 
In contrast, rpmsg provides only a single communication channel, so a type field is required to distinguish between 
different kinds of messages.

Since rpmsg replies and events share the same message format, an additional line is introduced to handle both cases.

Finally, rpmsg supports multiple GPIO controllers, so a port field is added to uniquely identify the target controller.

Shenwei

>        Andrew

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

[Mathieu Poirier]

On Tue, Apr 28, 2026 at 03:24:59PM +0000, Shenwei Wang wrote:
> 
> 
> > -----Original Message-----
> > From: Andrew Lunn <andrew@lunn.ch>
> > Sent: Monday, April 27, 2026 3:49 PM
> > To: Shenwei Wang <shenwei.wang@nxp.com>
> > Cc: Padhi, Beleswar <b-padhi@ti.com>; Linus Walleij <linusw@kernel.org>;
> > Bartosz Golaszewski <brgl@kernel.org>; Jonathan Corbet <corbet@lwn.net>;
> > Rob Herring <robh@kernel.org>; Krzysztof Kozlowski <krzk+dt@kernel.org>;
> > Conor Dooley <conor+dt@kernel.org>; Bjorn Andersson
> > <andersson@kernel.org>; Mathieu Poirier <mathieu.poirier@linaro.org>; Frank Li
> > <frank.li@nxp.com>; Sascha Hauer <s.hauer@pengutronix.de>; Shuah Khan
> > <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
> > doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix Kernel Team
> > <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; Peng Fan
> > <peng.fan@nxp.com>; devicetree@vger.kernel.org; linux-
> > remoteproc@vger.kernel.org; imx@lists.linux.dev; linux-arm-
> > kernel@lists.infradead.org; dl-linux-imx <linux-imx@nxp.com>; Bartosz
> > Golaszewski <brgl@bgdev.pl>
> > Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
> > > > struct virtio_gpio_response {
> > > >         __u8 status;
> > > >         __u8 value;
> > > > };
> > 
> > > It is the same message format. Please see the message definition
> > (GET_DIRECTION) below:
> > 
> > > +   +-----+-----+-----+-----+-----+----+
> > > +   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
> > > +   | 1   | 2   |port |line | err | dir|
> > > +   +-----+-----+-----+-----+-----+----+
> > 
> > Sorry, but i don't see how two u8 vs six u8 are the same message format.
> > 
> 
> Some changes to the message format are necessary.
> 
> Virtio uses two communication channels (virtqueues): one for requests and replies, and a second one for events. 
> In contrast, rpmsg provides only a single communication channel, so a type field is required to distinguish between 
> different kinds of messages.
> 
> Since rpmsg replies and events share the same message format, an additional line is introduced to handle both cases.
> 
> Finally, rpmsg supports multiple GPIO controllers, so a port field is added to uniquely identify the target controller.

I have commented on this before - RPMSG is already providing multiplexing
capability by way of endpoints.  There is no need for a port field.  One
endpoint, one GPIO controller. 

> 
> Shenwei
> 
> >        Andrew

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

[Shenwei Wang]

> -----Original Message-----
> From: Mathieu Poirier <mathieu.poirier@linaro.org>
> Sent: Wednesday, April 29, 2026 10:42 AM
> To: Shenwei Wang <shenwei.wang@nxp.com>
> Cc: Andrew Lunn <andrew@lunn.ch>; Padhi, Beleswar <b-padhi@ti.com>; Linus
> Walleij <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>; Jonathan
> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof Kozlowski
> <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn Andersson
> <andersson@kernel.org>; Frank Li <frank.li@nxp.com>; Sascha Hauer
> <s.hauer@pengutronix.de>; Shuah Khan <skhan@linuxfoundation.org>; linux-
> gpio@vger.kernel.org; linux-doc@vger.kernel.org; linux-kernel@vger.kernel.org;
> Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
> devicetree@vger.kernel.org; linux-remoteproc@vger.kernel.org;
> imx@lists.linux.dev; linux-arm-kernel@lists.infradead.org; dl-linux-imx <linux-
> imx@nxp.com>; Bartosz Golaszewski <brgl@bgdev.pl>
> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
> On Tue, Apr 28, 2026 at 03:24:59PM +0000, Shenwei Wang wrote:
> >
> >
> > > -----Original Message-----
> > > From: Andrew Lunn <andrew@lunn.ch>
> > > Sent: Monday, April 27, 2026 3:49 PM
> > > To: Shenwei Wang <shenwei.wang@nxp.com>
> > > Cc: Padhi, Beleswar <b-padhi@ti.com>; Linus Walleij
> > > <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>; Jonathan
> > > Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof
> > > Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>;
> > > Bjorn Andersson <andersson@kernel.org>; Mathieu Poirier
> > > <mathieu.poirier@linaro.org>; Frank Li <frank.li@nxp.com>; Sascha
> > > Hauer <s.hauer@pengutronix.de>; Shuah Khan
> > > <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
> > > doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix
> > > Kernel Team <kernel@pengutronix.de>; Fabio Estevam
> > > <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
> > > devicetree@vger.kernel.org; linux- remoteproc@vger.kernel.org;
> > > imx@lists.linux.dev; linux-arm- kernel@lists.infradead.org;
> > > dl-linux-imx <linux-imx@nxp.com>; Bartosz Golaszewski
> > > <brgl@bgdev.pl>
> > > Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg
> > > GPIO driver
> > > > > struct virtio_gpio_response {
> > > > >         __u8 status;
> > > > >         __u8 value;
> > > > > };
> > >
> > > > It is the same message format. Please see the message definition
> > > (GET_DIRECTION) below:
> > >
> > > > +   +-----+-----+-----+-----+-----+----+
> > > > +   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
> > > > +   | 1   | 2   |port |line | err | dir|
> > > > +   +-----+-----+-----+-----+-----+----+
> > >
> > > Sorry, but i don't see how two u8 vs six u8 are the same message format.
> > >
> >
> > Some changes to the message format are necessary.
> >
> > Virtio uses two communication channels (virtqueues): one for requests and
> replies, and a second one for events.
> > In contrast, rpmsg provides only a single communication channel, so a
> > type field is required to distinguish between different kinds of messages.
> >
> > Since rpmsg replies and events share the same message format, an additional
> line is introduced to handle both cases.
> >
> > Finally, rpmsg supports multiple GPIO controllers, so a port field is added to
> uniquely identify the target controller.
> 
> I have commented on this before - RPMSG is already providing multiplexing
> capability by way of endpoints.  There is no need for a port field.  One endpoint,
> one GPIO controller.
> 

You still need a way to let the remote side know which port the endpoint maps to, either 
by embedding the port information in the message (the current way), or by sending it 
separately.

Shenwei

> >
> > Shenwei
> >
> > >        Andrew

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

[Mathieu Poirier]

On Wed, 29 Apr 2026 at 10:53, Shenwei Wang <shenwei.wang@nxp.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Sent: Wednesday, April 29, 2026 10:42 AM
> > To: Shenwei Wang <shenwei.wang@nxp.com>
> > Cc: Andrew Lunn <andrew@lunn.ch>; Padhi, Beleswar <b-padhi@ti.com>; Linus
> > Walleij <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>; Jonathan
> > Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof Kozlowski
> > <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn Andersson
> > <andersson@kernel.org>; Frank Li <frank.li@nxp.com>; Sascha Hauer
> > <s.hauer@pengutronix.de>; Shuah Khan <skhan@linuxfoundation.org>; linux-
> > gpio@vger.kernel.org; linux-doc@vger.kernel.org; linux-kernel@vger.kernel.org;
> > Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
> > <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
> > devicetree@vger.kernel.org; linux-remoteproc@vger.kernel.org;
> > imx@lists.linux.dev; linux-arm-kernel@lists.infradead.org; dl-linux-imx <linux-
> > imx@nxp.com>; Bartosz Golaszewski <brgl@bgdev.pl>
> > Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
> > On Tue, Apr 28, 2026 at 03:24:59PM +0000, Shenwei Wang wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Andrew Lunn <andrew@lunn.ch>
> > > > Sent: Monday, April 27, 2026 3:49 PM
> > > > To: Shenwei Wang <shenwei.wang@nxp.com>
> > > > Cc: Padhi, Beleswar <b-padhi@ti.com>; Linus Walleij
> > > > <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>; Jonathan
> > > > Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof
> > > > Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>;
> > > > Bjorn Andersson <andersson@kernel.org>; Mathieu Poirier
> > > > <mathieu.poirier@linaro.org>; Frank Li <frank.li@nxp.com>; Sascha
> > > > Hauer <s.hauer@pengutronix.de>; Shuah Khan
> > > > <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
> > > > doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix
> > > > Kernel Team <kernel@pengutronix.de>; Fabio Estevam
> > > > <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
> > > > devicetree@vger.kernel.org; linux- remoteproc@vger.kernel.org;
> > > > imx@lists.linux.dev; linux-arm- kernel@lists.infradead.org;
> > > > dl-linux-imx <linux-imx@nxp.com>; Bartosz Golaszewski
> > > > <brgl@bgdev.pl>
> > > > Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg
> > > > GPIO driver
> > > > > > struct virtio_gpio_response {
> > > > > >         __u8 status;
> > > > > >         __u8 value;
> > > > > > };
> > > >
> > > > > It is the same message format. Please see the message definition
> > > > (GET_DIRECTION) below:
> > > >
> > > > > +   +-----+-----+-----+-----+-----+----+
> > > > > +   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
> > > > > +   | 1   | 2   |port |line | err | dir|
> > > > > +   +-----+-----+-----+-----+-----+----+
> > > >
> > > > Sorry, but i don't see how two u8 vs six u8 are the same message format.
> > > >
> > >
> > > Some changes to the message format are necessary.
> > >
> > > Virtio uses two communication channels (virtqueues): one for requests and
> > replies, and a second one for events.
> > > In contrast, rpmsg provides only a single communication channel, so a
> > > type field is required to distinguish between different kinds of messages.
> > >
> > > Since rpmsg replies and events share the same message format, an additional
> > line is introduced to handle both cases.
> > >
> > > Finally, rpmsg supports multiple GPIO controllers, so a port field is added to
> > uniquely identify the target controller.
> >
> > I have commented on this before - RPMSG is already providing multiplexing
> > capability by way of endpoints.  There is no need for a port field.  One endpoint,
> > one GPIO controller.
> >
>
> You still need a way to let the remote side know which port the endpoint maps to, either
> by embedding the port information in the message (the current way), or by sending it
> separately.
>

An endpoint is created with every namespace request.  There should be
one namespace request for every GPIO controller, which yields a unique
endpoint for each controller and eliminates the need for an extra
field to identify them.

> Shenwei
>
> > >
> > > Shenwei
> > >
> > > >        Andrew

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

[Padhi, Beleswar]

Hi Mathieu,

On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
> On Wed, 29 Apr 2026 at 10:53, Shenwei Wang <shenwei.wang@nxp.com> wrote:
>>
>>
>>> -----Original Message-----
>>> From: Mathieu Poirier <mathieu.poirier@linaro.org>
>>> Sent: Wednesday, April 29, 2026 10:42 AM
>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>> Cc: Andrew Lunn <andrew@lunn.ch>; Padhi, Beleswar <b-padhi@ti.com>; Linus
>>> Walleij <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>; Jonathan
>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof Kozlowski
>>> <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn Andersson
>>> <andersson@kernel.org>; Frank Li <frank.li@nxp.com>; Sascha Hauer
>>> <s.hauer@pengutronix.de>; Shuah Khan <skhan@linuxfoundation.org>; linux-
>>> gpio@vger.kernel.org; linux-doc@vger.kernel.org; linux-kernel@vger.kernel.org;
>>> Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>> devicetree@vger.kernel.org; linux-remoteproc@vger.kernel.org;
>>> imx@lists.linux.dev; linux-arm-kernel@lists.infradead.org; dl-linux-imx <linux-
>>> imx@nxp.com>; Bartosz Golaszewski <brgl@bgdev.pl>
>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
>>> On Tue, Apr 28, 2026 at 03:24:59PM +0000, Shenwei Wang wrote:
>>>>
>>>>> -----Original Message-----
>>>>> From: Andrew Lunn <andrew@lunn.ch>
>>>>> Sent: Monday, April 27, 2026 3:49 PM
>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>>> Cc: Padhi, Beleswar <b-padhi@ti.com>; Linus Walleij
>>>>> <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>; Jonathan
>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof
>>>>> Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>;
>>>>> Bjorn Andersson <andersson@kernel.org>; Mathieu Poirier
>>>>> <mathieu.poirier@linaro.org>; Frank Li <frank.li@nxp.com>; Sascha
>>>>> Hauer <s.hauer@pengutronix.de>; Shuah Khan
>>>>> <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
>>>>> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix
>>>>> Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>>>> devicetree@vger.kernel.org; linux- remoteproc@vger.kernel.org;
>>>>> imx@lists.linux.dev; linux-arm- kernel@lists.infradead.org;
>>>>> dl-linux-imx <linux-imx@nxp.com>; Bartosz Golaszewski
>>>>> <brgl@bgdev.pl>
>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg
>>>>> GPIO driver
>>>>>>> struct virtio_gpio_response {
>>>>>>>          __u8 status;
>>>>>>>          __u8 value;
>>>>>>> };
>>>>>> It is the same message format. Please see the message definition
>>>>> (GET_DIRECTION) below:
>>>>>
>>>>>> +   +-----+-----+-----+-----+-----+----+
>>>>>> +   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
>>>>>> +   | 1   | 2   |port |line | err | dir|
>>>>>> +   +-----+-----+-----+-----+-----+----+
>>>>> Sorry, but i don't see how two u8 vs six u8 are the same message format.
>>>>>
>>>> Some changes to the message format are necessary.
>>>>
>>>> Virtio uses two communication channels (virtqueues): one for requests and
>>> replies, and a second one for events.
>>>> In contrast, rpmsg provides only a single communication channel, so a
>>>> type field is required to distinguish between different kinds of messages.
>>>>
>>>> Since rpmsg replies and events share the same message format, an additional
>>> line is introduced to handle both cases.
>>>> Finally, rpmsg supports multiple GPIO controllers, so a port field is added to
>>> uniquely identify the target controller.
>>>
>>> I have commented on this before - RPMSG is already providing multiplexing
>>> capability by way of endpoints.  There is no need for a port field.  One endpoint,
>>> one GPIO controller.
>>>
>> You still need a way to let the remote side know which port the endpoint maps to, either
>> by embedding the port information in the message (the current way), or by sending it
>> separately.
>>
> An endpoint is created with every namespace request.  There should be
> one namespace request for every GPIO controller, which yields a unique
> endpoint for each controller and eliminates the need for an extra
> field to identify them.


Right, but this can still be done by just having one namespace request.
We can create new endpoints bound to an existing namespace/channel by
invoking rpmsg_create_ept(). This is what I suggested here too:
https://lore.kernel.org/all/29485742-6e49-482e-b73d-228295daaeec@ti.com/

My mental model looks like this for the complete picture:

1. namespace/channel#1 = rpmsg-io
    a. ept1 -> gpio-controller@1
    b. ept2 -> gpio-controller@2

2. namespace/channel#2 = rpmsg-i2c
    a. ept1 -> i2c@1
    b. ept2 -> i2c@2
    c. ept3 -> i2c@3

etc...

This way device groups are isolated with each channel/namespace, and
instances within each device groups are also respected with specific
endpoints.

Thanks,
Beleswar

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

[Shenwei Wang]

> -----Original Message-----
> From: Padhi, Beleswar <b-padhi@ti.com>
> Sent: Wednesday, April 29, 2026 1:07 PM
> To: Mathieu Poirier <mathieu.poirier@linaro.org>; Shenwei Wang
> <shenwei.wang@nxp.com>
> Cc: Andrew Lunn <andrew@lunn.ch>; Linus Walleij <linusw@kernel.org>; Bartosz
> Golaszewski <brgl@kernel.org>; Jonathan Corbet <corbet@lwn.net>; Rob Herring
> <robh@kernel.org>; Krzysztof Kozlowski <krzk+dt@kernel.org>; Conor Dooley
> <conor+dt@kernel.org>; Bjorn Andersson <andersson@kernel.org>; Frank Li
> <frank.li@nxp.com>; Sascha Hauer <s.hauer@pengutronix.de>; Shuah Khan
> <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix Kernel Team
> <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; Peng Fan
> <peng.fan@nxp.com>; devicetree@vger.kernel.org; linux-
> remoteproc@vger.kernel.org; imx@lists.linux.dev; linux-arm-
> kernel@lists.infradead.org; dl-linux-imx <linux-imx@nxp.com>; Bartosz
> Golaszewski <brgl@bgdev.pl>
> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
> Hi Mathieu,
>
> On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
> > On Wed, 29 Apr 2026 at 10:53, Shenwei Wang <shenwei.wang@nxp.com>
> wrote:
> >>
> >>
> >>> -----Original Message-----
> >>> From: Mathieu Poirier <mathieu.poirier@linaro.org>
> >>> Sent: Wednesday, April 29, 2026 10:42 AM
> >>> To: Shenwei Wang <shenwei.wang@nxp.com>
> >>> Cc: Andrew Lunn <andrew@lunn.ch>; Padhi, Beleswar <b-padhi@ti.com>;
> >>> Linus Walleij <linusw@kernel.org>; Bartosz Golaszewski
> >>> <brgl@kernel.org>; Jonathan Corbet <corbet@lwn.net>; Rob Herring
> >>> <robh@kernel.org>; Krzysztof Kozlowski <krzk+dt@kernel.org>; Conor
> >>> Dooley <conor+dt@kernel.org>; Bjorn Andersson
> >>> <andersson@kernel.org>; Frank Li <frank.li@nxp.com>; Sascha Hauer
> >>> <s.hauer@pengutronix.de>; Shuah Khan <skhan@linuxfoundation.org>;
> >>> linux- gpio@vger.kernel.org; linux-doc@vger.kernel.org;
> >>> linux-kernel@vger.kernel.org; Pengutronix Kernel Team
> >>> <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; Peng
> >>> Fan <peng.fan@nxp.com>; devicetree@vger.kernel.org;
> >>> linux-remoteproc@vger.kernel.org; imx@lists.linux.dev;
> >>> linux-arm-kernel@lists.infradead.org; dl-linux-imx <linux-
> >>> imx@nxp.com>; Bartosz Golaszewski <brgl@bgdev.pl>
> >>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg
> >>> GPIO driver On Tue, Apr 28, 2026 at 03:24:59PM +0000, Shenwei Wang
> wrote:
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Andrew Lunn <andrew@lunn.ch>
> >>>>> Sent: Monday, April 27, 2026 3:49 PM
> >>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
> >>>>> Cc: Padhi, Beleswar <b-padhi@ti.com>; Linus Walleij
> >>>>> <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>;
> >>>>> Jonathan Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>;
> >>>>> Krzysztof Kozlowski <krzk+dt@kernel.org>; Conor Dooley
> >>>>> <conor+dt@kernel.org>; Bjorn Andersson <andersson@kernel.org>;
> >>>>> Mathieu Poirier <mathieu.poirier@linaro.org>; Frank Li
> >>>>> <frank.li@nxp.com>; Sascha Hauer <s.hauer@pengutronix.de>; Shuah
> >>>>> Khan <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org;
> >>>>> linux- doc@vger.kernel.org; linux-kernel@vger.kernel.org;
> >>>>> Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
> >>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
> >>>>> devicetree@vger.kernel.org; linux- remoteproc@vger.kernel.org;
> >>>>> imx@lists.linux.dev; linux-arm- kernel@lists.infradead.org;
> >>>>> dl-linux-imx <linux-imx@nxp.com>; Bartosz Golaszewski
> >>>>> <brgl@bgdev.pl>
> >>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg
> >>>>> GPIO driver
> >>>>>>> struct virtio_gpio_response {
> >>>>>>>          __u8 status;
> >>>>>>>          __u8 value;
> >>>>>>> };
> >>>>>> It is the same message format. Please see the message definition
> >>>>> (GET_DIRECTION) below:
> >>>>>
> >>>>>> +   +-----+-----+-----+-----+-----+----+
> >>>>>> +   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
> >>>>>> +   | 1   | 2   |port |line | err | dir|
> >>>>>> +   +-----+-----+-----+-----+-----+----+
> >>>>> Sorry, but i don't see how two u8 vs six u8 are the same message format.
> >>>>>
> >>>> Some changes to the message format are necessary.
> >>>>
> >>>> Virtio uses two communication channels (virtqueues): one for
> >>>> requests and
> >>> replies, and a second one for events.
> >>>> In contrast, rpmsg provides only a single communication channel, so
> >>>> a type field is required to distinguish between different kinds of messages.
> >>>>
> >>>> Since rpmsg replies and events share the same message format, an
> >>>> additional
> >>> line is introduced to handle both cases.
> >>>> Finally, rpmsg supports multiple GPIO controllers, so a port field
> >>>> is added to
> >>> uniquely identify the target controller.
> >>>
> >>> I have commented on this before - RPMSG is already providing
> >>> multiplexing capability by way of endpoints.  There is no need for a
> >>> port field.  One endpoint, one GPIO controller.
> >>>
> >> You still need a way to let the remote side know which port the
> >> endpoint maps to, either by embedding the port information in the
> >> message (the current way), or by sending it separately.
> >>
> > An endpoint is created with every namespace request.  There should be
> > one namespace request for every GPIO controller, which yields a unique
> > endpoint for each controller and eliminates the need for an extra
> > field to identify them.
>
>
> Right, but this can still be done by just having one namespace request.
> We can create new endpoints bound to an existing namespace/channel by
> invoking rpmsg_create_ept(). This is what I suggested here too:
> https://lore.kernel/
> .org%2Fall%2F29485742-6e49-482e-b73d-
> 228295daaeec%40ti.com%2F&data=05%7C02%7Cshenwei.wang%40nxp.com%7
> Caba62d7a899849fd57f708dea61a1d8b%7C686ea1d3bc2b4c6fa92cd99c5c3016
> 35%7C0%7C0%7C639130828278097401%7CUnknown%7CTWFpbGZsb3d8eyJFb
> XB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb
> CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=NLLYQ0NZCnYKLT%2F2OMDZE
> SKgC%2Fme3FoUNqqEGBOIY2k%3D&reserved=0
>
> My mental model looks like this for the complete picture:
>
> 1. namespace/channel#1 = rpmsg-io
>     a. ept1 -> gpio-controller@1
>     b. ept2 -> gpio-controller@2
>
> 2. namespace/channel#2 = rpmsg-i2c
>     a. ept1 -> i2c@1
>     b. ept2 -> i2c@2
>     c. ept3 -> i2c@3
>

The GPIO nodes will act as providers.
Mapping the port index into the service name is a possible solution, but I don't believe it's better than
embedding that information in the message. A stateless approach feels simpler and cleaner overall.

Thanks,
Shenwei


> etc...
>
> This way device groups are isolated with each channel/namespace, and instances
> within each device groups are also respected with specific endpoints.
>
> Thanks,
> Beleswar

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

[Padhi, Beleswar]

On 4/30/2026 12:05 AM, Shenwei Wang wrote:
>
>> -----Original Message-----
>> From: Padhi, Beleswar <b-padhi@ti.com>
>> Sent: Wednesday, April 29, 2026 1:07 PM
>> To: Mathieu Poirier <mathieu.poirier@linaro.org>; Shenwei Wang
>> <shenwei.wang@nxp.com>
>> Cc: Andrew Lunn <andrew@lunn.ch>; Linus Walleij <linusw@kernel.org>; Bartosz
>> Golaszewski <brgl@kernel.org>; Jonathan Corbet <corbet@lwn.net>; Rob Herring
>> <robh@kernel.org>; Krzysztof Kozlowski <krzk+dt@kernel.org>; Conor Dooley
>> <conor+dt@kernel.org>; Bjorn Andersson <andersson@kernel.org>; Frank Li
>> <frank.li@nxp.com>; Sascha Hauer <s.hauer@pengutronix.de>; Shuah Khan
>> <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
>> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix Kernel Team
>> <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; Peng Fan
>> <peng.fan@nxp.com>; devicetree@vger.kernel.org; linux-
>> remoteproc@vger.kernel.org; imx@lists.linux.dev; linux-arm-
>> kernel@lists.infradead.org; dl-linux-imx <linux-imx@nxp.com>; Bartosz
>> Golaszewski <brgl@bgdev.pl>
>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
>> Hi Mathieu,
>>
>> On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
>>> On Wed, 29 Apr 2026 at 10:53, Shenwei Wang <shenwei.wang@nxp.com>
>> wrote:
>>>>
>>>>> -----Original Message-----
>>>>> From: Mathieu Poirier <mathieu.poirier@linaro.org>
>>>>> Sent: Wednesday, April 29, 2026 10:42 AM
>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>>> Cc: Andrew Lunn <andrew@lunn.ch>; Padhi, Beleswar <b-padhi@ti.com>;
>>>>> Linus Walleij <linusw@kernel.org>; Bartosz Golaszewski
>>>>> <brgl@kernel.org>; Jonathan Corbet <corbet@lwn.net>; Rob Herring
>>>>> <robh@kernel.org>; Krzysztof Kozlowski <krzk+dt@kernel.org>; Conor
>>>>> Dooley <conor+dt@kernel.org>; Bjorn Andersson
>>>>> <andersson@kernel.org>; Frank Li <frank.li@nxp.com>; Sascha Hauer
>>>>> <s.hauer@pengutronix.de>; Shuah Khan <skhan@linuxfoundation.org>;
>>>>> linux- gpio@vger.kernel.org; linux-doc@vger.kernel.org;
>>>>> linux-kernel@vger.kernel.org; Pengutronix Kernel Team
>>>>> <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; Peng
>>>>> Fan <peng.fan@nxp.com>; devicetree@vger.kernel.org;
>>>>> linux-remoteproc@vger.kernel.org; imx@lists.linux.dev;
>>>>> linux-arm-kernel@lists.infradead.org; dl-linux-imx <linux-
>>>>> imx@nxp.com>; Bartosz Golaszewski <brgl@bgdev.pl>
>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg
>>>>> GPIO driver On Tue, Apr 28, 2026 at 03:24:59PM +0000, Shenwei Wang
>> wrote:
>>>>>>> -----Original Message-----
>>>>>>> From: Andrew Lunn <andrew@lunn.ch>
>>>>>>> Sent: Monday, April 27, 2026 3:49 PM
>>>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>> Cc: Padhi, Beleswar <b-padhi@ti.com>; Linus Walleij
>>>>>>> <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>;
>>>>>>> Jonathan Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>;
>>>>>>> Krzysztof Kozlowski <krzk+dt@kernel.org>; Conor Dooley
>>>>>>> <conor+dt@kernel.org>; Bjorn Andersson <andersson@kernel.org>;
>>>>>>> Mathieu Poirier <mathieu.poirier@linaro.org>; Frank Li
>>>>>>> <frank.li@nxp.com>; Sascha Hauer <s.hauer@pengutronix.de>; Shuah
>>>>>>> Khan <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org;
>>>>>>> linux- doc@vger.kernel.org; linux-kernel@vger.kernel.org;
>>>>>>> Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>>>>>> devicetree@vger.kernel.org; linux- remoteproc@vger.kernel.org;
>>>>>>> imx@lists.linux.dev; linux-arm- kernel@lists.infradead.org;
>>>>>>> dl-linux-imx <linux-imx@nxp.com>; Bartosz Golaszewski
>>>>>>> <brgl@bgdev.pl>
>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg
>>>>>>> GPIO driver
>>>>>>>>> struct virtio_gpio_response {
>>>>>>>>>           __u8 status;
>>>>>>>>>           __u8 value;
>>>>>>>>> };
>>>>>>>> It is the same message format. Please see the message definition
>>>>>>> (GET_DIRECTION) below:
>>>>>>>
>>>>>>>> +   +-----+-----+-----+-----+-----+----+
>>>>>>>> +   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
>>>>>>>> +   | 1   | 2   |port |line | err | dir|
>>>>>>>> +   +-----+-----+-----+-----+-----+----+
>>>>>>> Sorry, but i don't see how two u8 vs six u8 are the same message format.
>>>>>>>
>>>>>> Some changes to the message format are necessary.
>>>>>>
>>>>>> Virtio uses two communication channels (virtqueues): one for
>>>>>> requests and
>>>>> replies, and a second one for events.
>>>>>> In contrast, rpmsg provides only a single communication channel, so
>>>>>> a type field is required to distinguish between different kinds of messages.
>>>>>>
>>>>>> Since rpmsg replies and events share the same message format, an
>>>>>> additional
>>>>> line is introduced to handle both cases.
>>>>>> Finally, rpmsg supports multiple GPIO controllers, so a port field
>>>>>> is added to
>>>>> uniquely identify the target controller.
>>>>>
>>>>> I have commented on this before - RPMSG is already providing
>>>>> multiplexing capability by way of endpoints.  There is no need for a
>>>>> port field.  One endpoint, one GPIO controller.
>>>>>
>>>> You still need a way to let the remote side know which port the
>>>> endpoint maps to, either by embedding the port information in the
>>>> message (the current way), or by sending it separately.
>>>>
>>> An endpoint is created with every namespace request.  There should be
>>> one namespace request for every GPIO controller, which yields a unique
>>> endpoint for each controller and eliminates the need for an extra
>>> field to identify them.
>>
>> Right, but this can still be done by just having one namespace request.
>> We can create new endpoints bound to an existing namespace/channel by
>> invoking rpmsg_create_ept(). This is what I suggested here too:
>> https://lore.kernel/
>> .org%2Fall%2F29485742-6e49-482e-b73d-
>> 228295daaeec%40ti.com%2F&data=05%7C02%7Cshenwei.wang%40nxp.com%7
>> Caba62d7a899849fd57f708dea61a1d8b%7C686ea1d3bc2b4c6fa92cd99c5c3016
>> 35%7C0%7C0%7C639130828278097401%7CUnknown%7CTWFpbGZsb3d8eyJFb
>> XB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb
>> CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=NLLYQ0NZCnYKLT%2F2OMDZE
>> SKgC%2Fme3FoUNqqEGBOIY2k%3D&reserved=0
>>
>> My mental model looks like this for the complete picture:
>>
>> 1. namespace/channel#1 = rpmsg-io
>>      a. ept1 -> gpio-controller@1
>>      b. ept2 -> gpio-controller@2
>>
>> 2. namespace/channel#2 = rpmsg-i2c
>>      a. ept1 -> i2c@1
>>      b. ept2 -> i2c@2
>>      c. ept3 -> i2c@3
>>
> The GPIO nodes will act as providers.
> Mapping the port index into the service name is a possible solution,


I am not suggesting this. Infact the opposite. Let there be a single
rpmsg service "rpmsg-io" for gpio. And multiple endpoints within
the service, each for one controller. Once you have relayed this info
(dynamic ept addr corresponding to each port) back to the
firmware, you no longer need the "port" field in the message
anymore.

Did you get a chance to analyze this?:
https://lore.kernel.org/all/a067452a-9a8d-45ea-8bef-b44f851da7b2@ti.com/

Thanks,
Beleswar

>   but I don't believe it's better than
> embedding that information in the message. A stateless approach feels simpler and cleaner overall.
>
> Thanks,
> Shenwei
>
>
>> etc...
>>
>> This way device groups are isolated with each channel/namespace, and instances
>> within each device groups are also respected with specific endpoints.
>>
>> Thanks,
>> Beleswar

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

[Mathieu Poirier]

On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar <b-padhi@ti.com> wrote:
>
> Hi Mathieu,
>
> On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
> > On Wed, 29 Apr 2026 at 10:53, Shenwei Wang <shenwei.wang@nxp.com> wrote:
> >>
> >>
> >>> -----Original Message-----
> >>> From: Mathieu Poirier <mathieu.poirier@linaro.org>
> >>> Sent: Wednesday, April 29, 2026 10:42 AM
> >>> To: Shenwei Wang <shenwei.wang@nxp.com>
> >>> Cc: Andrew Lunn <andrew@lunn.ch>; Padhi, Beleswar <b-padhi@ti.com>; Linus
> >>> Walleij <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>; Jonathan
> >>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof Kozlowski
> >>> <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn Andersson
> >>> <andersson@kernel.org>; Frank Li <frank.li@nxp.com>; Sascha Hauer
> >>> <s.hauer@pengutronix.de>; Shuah Khan <skhan@linuxfoundation.org>; linux-
> >>> gpio@vger.kernel.org; linux-doc@vger.kernel.org; linux-kernel@vger.kernel.org;
> >>> Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
> >>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
> >>> devicetree@vger.kernel.org; linux-remoteproc@vger.kernel.org;
> >>> imx@lists.linux.dev; linux-arm-kernel@lists.infradead.org; dl-linux-imx <linux-
> >>> imx@nxp.com>; Bartosz Golaszewski <brgl@bgdev.pl>
> >>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
> >>> On Tue, Apr 28, 2026 at 03:24:59PM +0000, Shenwei Wang wrote:
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Andrew Lunn <andrew@lunn.ch>
> >>>>> Sent: Monday, April 27, 2026 3:49 PM
> >>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
> >>>>> Cc: Padhi, Beleswar <b-padhi@ti.com>; Linus Walleij
> >>>>> <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>; Jonathan
> >>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof
> >>>>> Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>;
> >>>>> Bjorn Andersson <andersson@kernel.org>; Mathieu Poirier
> >>>>> <mathieu.poirier@linaro.org>; Frank Li <frank.li@nxp.com>; Sascha
> >>>>> Hauer <s.hauer@pengutronix.de>; Shuah Khan
> >>>>> <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
> >>>>> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix
> >>>>> Kernel Team <kernel@pengutronix.de>; Fabio Estevam
> >>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
> >>>>> devicetree@vger.kernel.org; linux- remoteproc@vger.kernel.org;
> >>>>> imx@lists.linux.dev; linux-arm- kernel@lists.infradead.org;
> >>>>> dl-linux-imx <linux-imx@nxp.com>; Bartosz Golaszewski
> >>>>> <brgl@bgdev.pl>
> >>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg
> >>>>> GPIO driver
> >>>>>>> struct virtio_gpio_response {
> >>>>>>>          __u8 status;
> >>>>>>>          __u8 value;
> >>>>>>> };
> >>>>>> It is the same message format. Please see the message definition
> >>>>> (GET_DIRECTION) below:
> >>>>>
> >>>>>> +   +-----+-----+-----+-----+-----+----+
> >>>>>> +   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
> >>>>>> +   | 1   | 2   |port |line | err | dir|
> >>>>>> +   +-----+-----+-----+-----+-----+----+
> >>>>> Sorry, but i don't see how two u8 vs six u8 are the same message format.
> >>>>>
> >>>> Some changes to the message format are necessary.
> >>>>
> >>>> Virtio uses two communication channels (virtqueues): one for requests and
> >>> replies, and a second one for events.
> >>>> In contrast, rpmsg provides only a single communication channel, so a
> >>>> type field is required to distinguish between different kinds of messages.
> >>>>
> >>>> Since rpmsg replies and events share the same message format, an additional
> >>> line is introduced to handle both cases.
> >>>> Finally, rpmsg supports multiple GPIO controllers, so a port field is added to
> >>> uniquely identify the target controller.
> >>>
> >>> I have commented on this before - RPMSG is already providing multiplexing
> >>> capability by way of endpoints.  There is no need for a port field.  One endpoint,
> >>> one GPIO controller.
> >>>
> >> You still need a way to let the remote side know which port the endpoint maps to, either
> >> by embedding the port information in the message (the current way), or by sending it
> >> separately.
> >>
> > An endpoint is created with every namespace request.  There should be
> > one namespace request for every GPIO controller, which yields a unique
> > endpoint for each controller and eliminates the need for an extra
> > field to identify them.
>
>
> Right, but this can still be done by just having one namespace request.
> We can create new endpoints bound to an existing namespace/channel by
> invoking rpmsg_create_ept(). This is what I suggested here too:
> https://lore.kernel.org/all/29485742-6e49-482e-b73d-228295daaeec@ti.com/
>

I will look at your suggestion (i.e link above) later this week or next week.

> My mental model looks like this for the complete picture:
>
> 1. namespace/channel#1 = rpmsg-io
>     a. ept1 -> gpio-controller@1
>     b. ept2 -> gpio-controller@2
>

I've asked for one endpoint per GPIO controller since the very
beginning.  I don't yet have a strong opinion on whether to use one
namespace request per GPIO controller or a single request that spins
off multiple endpoints.  I'll have to look at your link and reflect on
that.  Regardless of how we proceed on that front, multiplexing needs
to happen at the endpoint level rather than the packet level.  This is
the only way this work can move forward.

> 2. namespace/channel#2 = rpmsg-i2c
>     a. ept1 -> i2c@1
>     b. ept2 -> i2c@2
>     c. ept3 -> i2c@3
>
> etc...
>
> This way device groups are isolated with each channel/namespace, and
> instances within each device groups are also respected with specific
> endpoints.
>
> Thanks,
> Beleswar
>

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

[Arnaud POULIQUEN]

Hello,

On 4/29/26 21:20, Mathieu Poirier wrote:
> On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar <b-padhi@ti.com> wrote:
>>
>> Hi Mathieu,
>>
>> On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
>>> On Wed, 29 Apr 2026 at 10:53, Shenwei Wang <shenwei.wang@nxp.com> wrote:
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Mathieu Poirier <mathieu.poirier@linaro.org>
>>>>> Sent: Wednesday, April 29, 2026 10:42 AM
>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>>> Cc: Andrew Lunn <andrew@lunn.ch>; Padhi, Beleswar <b-padhi@ti.com>; Linus
>>>>> Walleij <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>; Jonathan
>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof Kozlowski
>>>>> <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn Andersson
>>>>> <andersson@kernel.org>; Frank Li <frank.li@nxp.com>; Sascha Hauer
>>>>> <s.hauer@pengutronix.de>; Shuah Khan <skhan@linuxfoundation.org>; linux-
>>>>> gpio@vger.kernel.org; linux-doc@vger.kernel.org; linux-kernel@vger.kernel.org;
>>>>> Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>>>> devicetree@vger.kernel.org; linux-remoteproc@vger.kernel.org;
>>>>> imx@lists.linux.dev; linux-arm-kernel@lists.infradead.org; dl-linux-imx <linux-
>>>>> imx@nxp.com>; Bartosz Golaszewski <brgl@bgdev.pl>
>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
>>>>> On Tue, Apr 28, 2026 at 03:24:59PM +0000, Shenwei Wang wrote:
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Andrew Lunn <andrew@lunn.ch>
>>>>>>> Sent: Monday, April 27, 2026 3:49 PM
>>>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>> Cc: Padhi, Beleswar <b-padhi@ti.com>; Linus Walleij
>>>>>>> <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>; Jonathan
>>>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof
>>>>>>> Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>;
>>>>>>> Bjorn Andersson <andersson@kernel.org>; Mathieu Poirier
>>>>>>> <mathieu.poirier@linaro.org>; Frank Li <frank.li@nxp.com>; Sascha
>>>>>>> Hauer <s.hauer@pengutronix.de>; Shuah Khan
>>>>>>> <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
>>>>>>> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix
>>>>>>> Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>>>>>> devicetree@vger.kernel.org; linux- remoteproc@vger.kernel.org;
>>>>>>> imx@lists.linux.dev; linux-arm- kernel@lists.infradead.org;
>>>>>>> dl-linux-imx <linux-imx@nxp.com>; Bartosz Golaszewski
>>>>>>> <brgl@bgdev.pl>
>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg
>>>>>>> GPIO driver
>>>>>>>>> struct virtio_gpio_response {
>>>>>>>>>           __u8 status;
>>>>>>>>>           __u8 value;
>>>>>>>>> };
>>>>>>>> It is the same message format. Please see the message definition
>>>>>>> (GET_DIRECTION) below:
>>>>>>>
>>>>>>>> +   +-----+-----+-----+-----+-----+----+
>>>>>>>> +   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
>>>>>>>> +   | 1   | 2   |port |line | err | dir|
>>>>>>>> +   +-----+-----+-----+-----+-----+----+
>>>>>>> Sorry, but i don't see how two u8 vs six u8 are the same message format.
>>>>>>>
>>>>>> Some changes to the message format are necessary.
>>>>>>
>>>>>> Virtio uses two communication channels (virtqueues): one for requests and
>>>>> replies, and a second one for events.
>>>>>> In contrast, rpmsg provides only a single communication channel, so a
>>>>>> type field is required to distinguish between different kinds of messages.
>>>>>>
>>>>>> Since rpmsg replies and events share the same message format, an additional
>>>>> line is introduced to handle both cases.
>>>>>> Finally, rpmsg supports multiple GPIO controllers, so a port field is added to
>>>>> uniquely identify the target controller.
>>>>>
>>>>> I have commented on this before - RPMSG is already providing multiplexing
>>>>> capability by way of endpoints.  There is no need for a port field.  One endpoint,
>>>>> one GPIO controller.
>>>>>
>>>> You still need a way to let the remote side know which port the endpoint maps to, either
>>>> by embedding the port information in the message (the current way), or by sending it
>>>> separately.
>>>>
>>> An endpoint is created with every namespace request.  There should be
>>> one namespace request for every GPIO controller, which yields a unique
>>> endpoint for each controller and eliminates the need for an extra
>>> field to identify them.
>>
>>
>> Right, but this can still be done by just having one namespace request.
>> We can create new endpoints bound to an existing namespace/channel by
>> invoking rpmsg_create_ept(). This is what I suggested here too:
>> https://lore.kernel.org/all/29485742-6e49-482e-b73d-228295daaeec@ti.com/
>>
> 
> I will look at your suggestion (i.e link above) later this week or next week.
> 
>> My mental model looks like this for the complete picture:
>>
>> 1. namespace/channel#1 = rpmsg-io
>>      a. ept1 -> gpio-controller@1
>>      b. ept2 -> gpio-controller@2
>>
> 
> I've asked for one endpoint per GPIO controller since the very
> beginning.  I don't yet have a strong opinion on whether to use one
> namespace request per GPIO controller or a single request that spins
> off multiple endpoints.  I'll have to look at your link and reflect on
> that.  Regardless of how we proceed on that front, multiplexing needs
> to happen at the endpoint level rather than the packet level.  This is
> the only way this work can move forward.
> 

I would be more in favor of Mathieu’s proposal: “An endpoint is created 
with every namespace request.”

If the endpoint is created only on the Linux side, how do we match the 
Linux endpoint address with the local port field on the remote side?

With a multi-namespace approach, the namespace could be rpmsg-io-[addr], 
where [addr] corresponds to the GPIO controller address in the DT. This 
would:

- match the RPMsg probe with the DT,
- provide a simple mapping between the port and the endpoint on both sides,
- allow multiple endpoints on the remote side,
- provide a simple discovery mechanism for remote capabilities.

Regards,
Arnaud

>> 2. namespace/channel#2 = rpmsg-i2c
>>      a. ept1 -> i2c@1
>>      b. ept2 -> i2c@2
>>      c. ept3 -> i2c@3
>>
>> etc...
>>
>> This way device groups are isolated with each channel/namespace, and
>> instances within each device groups are also respected with specific
>> endpoints.
>>
>> Thanks,
>> Beleswar
>>
> 

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

[Beleswar Prasad Padhi]

Hello Arnaud,

On 30/04/26 13:05, Arnaud POULIQUEN wrote:
> Hello,
>
> On 4/29/26 21:20, Mathieu Poirier wrote:
>> On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar <b-padhi@ti.com> wrote:
>>>
>>> Hi Mathieu,
>>>
>>> On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
>>>> On Wed, 29 Apr 2026 at 10:53, Shenwei Wang <shenwei.wang@nxp.com> wrote:
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Mathieu Poirier <mathieu.poirier@linaro.org>
>>>>>> Sent: Wednesday, April 29, 2026 10:42 AM
>>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>>>> Cc: Andrew Lunn <andrew@lunn.ch>; Padhi, Beleswar <b-padhi@ti.com>; Linus
>>>>>> Walleij <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>; Jonathan
>>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof Kozlowski
>>>>>> <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn Andersson
>>>>>> <andersson@kernel.org>; Frank Li <frank.li@nxp.com>; Sascha Hauer
>>>>>> <s.hauer@pengutronix.de>; Shuah Khan <skhan@linuxfoundation.org>; linux-
>>>>>> gpio@vger.kernel.org; linux-doc@vger.kernel.org; linux-kernel@vger.kernel.org;
>>>>>> Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>>>>> devicetree@vger.kernel.org; linux-remoteproc@vger.kernel.org;
>>>>>> imx@lists.linux.dev; linux-arm-kernel@lists.infradead.org; dl-linux-imx <linux-
>>>>>> imx@nxp.com>; Bartosz Golaszewski <brgl@bgdev.pl>
>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
>>>>>> On Tue, Apr 28, 2026 at 03:24:59PM +0000, Shenwei Wang wrote:
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Andrew Lunn <andrew@lunn.ch>
>>>>>>>> Sent: Monday, April 27, 2026 3:49 PM
>>>>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>>> Cc: Padhi, Beleswar <b-padhi@ti.com>; Linus Walleij
>>>>>>>> <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>; Jonathan
>>>>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof
>>>>>>>> Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>;
>>>>>>>> Bjorn Andersson <andersson@kernel.org>; Mathieu Poirier
>>>>>>>> <mathieu.poirier@linaro.org>; Frank Li <frank.li@nxp.com>; Sascha
>>>>>>>> Hauer <s.hauer@pengutronix.de>; Shuah Khan
>>>>>>>> <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
>>>>>>>> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix
>>>>>>>> Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>>>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>>>>>>> devicetree@vger.kernel.org; linux- remoteproc@vger.kernel.org;
>>>>>>>> imx@lists.linux.dev; linux-arm- kernel@lists.infradead.org;
>>>>>>>> dl-linux-imx <linux-imx@nxp.com>; Bartosz Golaszewski
>>>>>>>> <brgl@bgdev.pl>
>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg
>>>>>>>> GPIO driver
>>>>>>>>>> struct virtio_gpio_response {
>>>>>>>>>>           __u8 status;
>>>>>>>>>>           __u8 value;
>>>>>>>>>> };
>>>>>>>>> It is the same message format. Please see the message definition
>>>>>>>> (GET_DIRECTION) below:
>>>>>>>>
>>>>>>>>> +   +-----+-----+-----+-----+-----+----+
>>>>>>>>> +   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
>>>>>>>>> +   | 1   | 2   |port |line | err | dir|
>>>>>>>>> +   +-----+-----+-----+-----+-----+----+
>>>>>>>> Sorry, but i don't see how two u8 vs six u8 are the same message format.
>>>>>>>>
>>>>>>> Some changes to the message format are necessary.
>>>>>>>
>>>>>>> Virtio uses two communication channels (virtqueues): one for requests and
>>>>>> replies, and a second one for events.
>>>>>>> In contrast, rpmsg provides only a single communication channel, so a
>>>>>>> type field is required to distinguish between different kinds of messages.
>>>>>>>
>>>>>>> Since rpmsg replies and events share the same message format, an additional
>>>>>> line is introduced to handle both cases.
>>>>>>> Finally, rpmsg supports multiple GPIO controllers, so a port field is added to
>>>>>> uniquely identify the target controller.
>>>>>>
>>>>>> I have commented on this before - RPMSG is already providing multiplexing
>>>>>> capability by way of endpoints.  There is no need for a port field.  One endpoint,
>>>>>> one GPIO controller.
>>>>>>
>>>>> You still need a way to let the remote side know which port the endpoint maps to, either
>>>>> by embedding the port information in the message (the current way), or by sending it
>>>>> separately.
>>>>>
>>>> An endpoint is created with every namespace request.  There should be
>>>> one namespace request for every GPIO controller, which yields a unique
>>>> endpoint for each controller and eliminates the need for an extra
>>>> field to identify them.
>>>
>>>
>>> Right, but this can still be done by just having one namespace request.
>>> We can create new endpoints bound to an existing namespace/channel by
>>> invoking rpmsg_create_ept(). This is what I suggested here too:
>>> https://lore.kernel.org/all/29485742-6e49-482e-b73d-228295daaeec@ti.com/
>>>
>>
>> I will look at your suggestion (i.e link above) later this week or next week.
>>
>>> My mental model looks like this for the complete picture:
>>>
>>> 1. namespace/channel#1 = rpmsg-io
>>>      a. ept1 -> gpio-controller@1
>>>      b. ept2 -> gpio-controller@2
>>>
>>
>> I've asked for one endpoint per GPIO controller since the very
>> beginning.  I don't yet have a strong opinion on whether to use one
>> namespace request per GPIO controller or a single request that spins
>> off multiple endpoints.  I'll have to look at your link and reflect on
>> that.  Regardless of how we proceed on that front, multiplexing needs
>> to happen at the endpoint level rather than the packet level.  This is
>> the only way this work can move forward.
>>
>
> I would be more in favor of Mathieu’s proposal: “An endpoint is created with every namespace request.”
>
> If the endpoint is created only on the Linux side, how do we match the Linux endpoint address with the local port field on the remote side? 


Simply by sending a message to the remote containing the newly created
endpoint and the port idx. Note that is this done just one time, after this
Linux need not have the port field in the message everytime its sending
a message.

>
> With a multi-namespace approach, the namespace could be rpmsg-io-[addr], where [addr] corresponds to the GPIO controller address in the DT. This would: 


You will face the same problem in this case also that you asked above:
"how do we match the Linux endpoint address with the local port field
on the remote side?"

Because the endpoint that is created on a namespace request is also
dynamic in nature. How will the remote know which endpoint addr
Linux allocated for a namespace that it announced?

As an example/PoC, I created a firmware example which announces
2 name services to Linux, one is the standard "rpmsg_chrdev" and
the other is a TI specific name service "ti.ipc4.ping-pong". You can
see it created 2 different addresses (0x400 and 0x401) for each of
the name service request from the same firmware:

root@j784s4-evm:~# dmesg | grep virtio0 | grep -i channel                                                                                                                                                   
[    9.290275] virtio_rpmsg_bus virtio0: creating channel ti.ipc4.ping-pong addr 0xd
[    9.311230] virtio_rpmsg_bus virtio0: creating channel rpmsg_chrdev addr 0xe
[    9.496645] rpmsg_chrdev virtio0.rpmsg_chrdev.-1.14: DEBUG: Channel formed from src = 0x400 to dst = 0xe
[    9.707255] rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.13: new channel: 0x401 -> 0xd!

So in this case, rpmsg-io-1 can have different ept addr than rpmsg-io-2
Back to same problem. Simple solution is to reply to remote with the
created ept addr and the index.
 

>
> - match the RPMsg probe with the DT, 


We can probe from all controllers with a single name service
announcement too.

> - provide a simple mapping between the port and the endpoint on both sides, 


We are trying to get rid of this mapping from Linux side to adapt
the gpio-virtio design.

> - allow multiple endpoints on the remote side, 


We can support this as well with single nameservice model.
There is no limitation. Remote has to send a message with
its newly created ept that's all.

> - provide a simple discovery mechanism for remote capabilities. 


A single announcement: "rpmsg-io" is also discovery mechanism.

Feel free to let me know if you have concerns with any of the
suggestions!

Thanks,
Beleswar

>
> Regards,
> Arnaud
>
>>> 2. namespace/channel#2 = rpmsg-i2c
>>>      a. ept1 -> i2c@1
>>>      b. ept2 -> i2c@2
>>>      c. ept3 -> i2c@3
>>>
>>> etc...
>>>
>>> This way device groups are isolated with each channel/namespace, and
>>> instances within each device groups are also respected with specific
>>> endpoints.
>>>
>>> Thanks,
>>> Beleswar
>>>
>>
>

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

[Arnaud POULIQUEN]

On 4/30/26 14:56, Beleswar Prasad Padhi wrote:
> Hello Arnaud,
> 
> On 30/04/26 13:05, Arnaud POULIQUEN wrote:
>> Hello,
>>
>> On 4/29/26 21:20, Mathieu Poirier wrote:
>>> On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar <b-padhi@ti.com> wrote:
>>>>
>>>> Hi Mathieu,
>>>>
>>>> On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
>>>>> On Wed, 29 Apr 2026 at 10:53, Shenwei Wang <shenwei.wang@nxp.com> wrote:
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Mathieu Poirier <mathieu.poirier@linaro.org>
>>>>>>> Sent: Wednesday, April 29, 2026 10:42 AM
>>>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>> Cc: Andrew Lunn <andrew@lunn.ch>; Padhi, Beleswar <b-padhi@ti.com>; Linus
>>>>>>> Walleij <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>; Jonathan
>>>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof Kozlowski
>>>>>>> <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn Andersson
>>>>>>> <andersson@kernel.org>; Frank Li <frank.li@nxp.com>; Sascha Hauer
>>>>>>> <s.hauer@pengutronix.de>; Shuah Khan <skhan@linuxfoundation.org>; linux-
>>>>>>> gpio@vger.kernel.org; linux-doc@vger.kernel.org; linux-kernel@vger.kernel.org;
>>>>>>> Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>>>>>> devicetree@vger.kernel.org; linux-remoteproc@vger.kernel.org;
>>>>>>> imx@lists.linux.dev; linux-arm-kernel@lists.infradead.org; dl-linux-imx <linux-
>>>>>>> imx@nxp.com>; Bartosz Golaszewski <brgl@bgdev.pl>
>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
>>>>>>> On Tue, Apr 28, 2026 at 03:24:59PM +0000, Shenwei Wang wrote:
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Andrew Lunn <andrew@lunn.ch>
>>>>>>>>> Sent: Monday, April 27, 2026 3:49 PM
>>>>>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>>>> Cc: Padhi, Beleswar <b-padhi@ti.com>; Linus Walleij
>>>>>>>>> <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>; Jonathan
>>>>>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof
>>>>>>>>> Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>;
>>>>>>>>> Bjorn Andersson <andersson@kernel.org>; Mathieu Poirier
>>>>>>>>> <mathieu.poirier@linaro.org>; Frank Li <frank.li@nxp.com>; Sascha
>>>>>>>>> Hauer <s.hauer@pengutronix.de>; Shuah Khan
>>>>>>>>> <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
>>>>>>>>> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix
>>>>>>>>> Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>>>>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>>>>>>>> devicetree@vger.kernel.org; linux- remoteproc@vger.kernel.org;
>>>>>>>>> imx@lists.linux.dev; linux-arm- kernel@lists.infradead.org;
>>>>>>>>> dl-linux-imx <linux-imx@nxp.com>; Bartosz Golaszewski
>>>>>>>>> <brgl@bgdev.pl>
>>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg
>>>>>>>>> GPIO driver
>>>>>>>>>>> struct virtio_gpio_response {
>>>>>>>>>>>            __u8 status;
>>>>>>>>>>>            __u8 value;
>>>>>>>>>>> };
>>>>>>>>>> It is the same message format. Please see the message definition
>>>>>>>>> (GET_DIRECTION) below:
>>>>>>>>>
>>>>>>>>>> +   +-----+-----+-----+-----+-----+----+
>>>>>>>>>> +   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
>>>>>>>>>> +   | 1   | 2   |port |line | err | dir|
>>>>>>>>>> +   +-----+-----+-----+-----+-----+----+
>>>>>>>>> Sorry, but i don't see how two u8 vs six u8 are the same message format.
>>>>>>>>>
>>>>>>>> Some changes to the message format are necessary.
>>>>>>>>
>>>>>>>> Virtio uses two communication channels (virtqueues): one for requests and
>>>>>>> replies, and a second one for events.
>>>>>>>> In contrast, rpmsg provides only a single communication channel, so a
>>>>>>>> type field is required to distinguish between different kinds of messages.
>>>>>>>>
>>>>>>>> Since rpmsg replies and events share the same message format, an additional
>>>>>>> line is introduced to handle both cases.
>>>>>>>> Finally, rpmsg supports multiple GPIO controllers, so a port field is added to
>>>>>>> uniquely identify the target controller.
>>>>>>>
>>>>>>> I have commented on this before - RPMSG is already providing multiplexing
>>>>>>> capability by way of endpoints.  There is no need for a port field.  One endpoint,
>>>>>>> one GPIO controller.
>>>>>>>
>>>>>> You still need a way to let the remote side know which port the endpoint maps to, either
>>>>>> by embedding the port information in the message (the current way), or by sending it
>>>>>> separately.
>>>>>>
>>>>> An endpoint is created with every namespace request.  There should be
>>>>> one namespace request for every GPIO controller, which yields a unique
>>>>> endpoint for each controller and eliminates the need for an extra
>>>>> field to identify them.
>>>>
>>>>
>>>> Right, but this can still be done by just having one namespace request.
>>>> We can create new endpoints bound to an existing namespace/channel by
>>>> invoking rpmsg_create_ept(). This is what I suggested here too:
>>>> https://lore.kernel.org/all/29485742-6e49-482e-b73d-228295daaeec@ti.com/
>>>>
>>>
>>> I will look at your suggestion (i.e link above) later this week or next week.
>>>
>>>> My mental model looks like this for the complete picture:
>>>>
>>>> 1. namespace/channel#1 = rpmsg-io
>>>>       a. ept1 -> gpio-controller@1
>>>>       b. ept2 -> gpio-controller@2
>>>>
>>>
>>> I've asked for one endpoint per GPIO controller since the very
>>> beginning.  I don't yet have a strong opinion on whether to use one
>>> namespace request per GPIO controller or a single request that spins
>>> off multiple endpoints.  I'll have to look at your link and reflect on
>>> that.  Regardless of how we proceed on that front, multiplexing needs
>>> to happen at the endpoint level rather than the packet level.  This is
>>> the only way this work can move forward.
>>>
>>
>> I would be more in favor of Mathieu’s proposal: “An endpoint is created with every namespace request.”
>>
>> If the endpoint is created only on the Linux side, how do we match the Linux endpoint address with the local port field on the remote side?
> 
> 
> Simply by sending a message to the remote containing the newly created
> endpoint and the port idx. Note that is this done just one time, after this
> Linux need not have the port field in the message everytime its sending
> a message.
> 
>>
>> With a multi-namespace approach, the namespace could be rpmsg-io-[addr], where [addr] corresponds to the GPIO controller address in the DT. This would:
> 
> 
> You will face the same problem in this case also that you asked above:
> "how do we match the Linux endpoint address with the local port field
> on the remote side?"

Sorry I probably introduced confusion here
my sentence should be;
  With a multi-namespace approach, the namespace could be rpmsg-io-[port],
  where [port] corresponds to the GPIO controller port in the DT.


For instance:

       rpmsg {
         rpmsg-io {
           #address-cells = <1>;
           #size-cells = <0>;

           gpio@25 {
             compatible = "rpmsg-gpio";
             reg = <25>;
             gpio-controller;
             #gpio-cells = <2>;
             #interrupt-cells = <2>;
             interrupt-controller;
           };

           gpio@32 {
             compatible = "rpmsg-gpio";
             reg = <32>;
             gpio-controller;
             #gpio-cells = <2>;
             #interrupt-cells = <2>;
             interrupt-controller;
           };
         };
       };

  rpmsg-io-25  would match with gpio@25
  rpmsg-io-32  would match with gpio@32


> 
> Because the endpoint that is created on a namespace request is also
> dynamic in nature. How will the remote know which endpoint addr
> Linux allocated for a namespace that it announced?
> 
> As an example/PoC, I created a firmware example which announces
> 2 name services to Linux, one is the standard "rpmsg_chrdev" and
> the other is a TI specific name service "ti.ipc4.ping-pong". You can
> see it created 2 different addresses (0x400 and 0x401) for each of
> the name service request from the same firmware:
> 
> root@j784s4-evm:~# dmesg | grep virtio0 | grep -i channel
> [    9.290275] virtio_rpmsg_bus virtio0: creating channel ti.ipc4.ping-pong addr 0xd
> [    9.311230] virtio_rpmsg_bus virtio0: creating channel rpmsg_chrdev addr 0xe
> [    9.496645] rpmsg_chrdev virtio0.rpmsg_chrdev.-1.14: DEBUG: Channel formed from src = 0x400 to dst = 0xe
> [    9.707255] rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.13: new channel: 0x401 -> 0xd!
> 
> So in this case, rpmsg-io-1 can have different ept addr than rpmsg-io-2
> Back to same problem. Simple solution is to reply to remote with the
> created ept addr and the index.

That why I would like to suggest to use the name service field to 
identify the port/controller, instead of the endpoint address.
>   
> 
>>
>> - match the RPMsg probe with the DT,
> 
> 
> We can probe from all controllers with a single name service
> announcement too.
> 
>> - provide a simple mapping between the port and the endpoint on both sides,
> 
> 
> We are trying to get rid of this mapping from Linux side to adapt
> the gpio-virtio design.
> 
>> - allow multiple endpoints on the remote side,
> 
> 
> We can support this as well with single nameservice model.
> There is no limitation. Remote has to send a message with
> its newly created ept that's all.
> 
>> - provide a simple discovery mechanism for remote capabilities.
> 
> 
> A single announcement: "rpmsg-io" is also discovery mechanism.
> 
> Feel free to let me know if you have concerns with any of the
> suggestions!

My only concern, whatever the solution, is that we find a smart
solution to associate the correct endpoint with the correct GPIO
port/controller defined in the DT.

I may have misunderstood your solution. Could you please help me
understand your proposal by explaining how you would handle three
GPIO ports defined in the DT, considering that the endpoint
addresses on the Linux side can be random?
If I assume there is a unique endpoint on the remote side,
I do not understand how you can match, on the firmware side,
the Linux endpoint address to the GPIO port.

Thanks and Regards,Arnaud

> 
> Thanks,
> Beleswar
> 
>>
>> Regards,
>> Arnaud
>>
>>>> 2. namespace/channel#2 = rpmsg-i2c
>>>>       a. ept1 -> i2c@1
>>>>       b. ept2 -> i2c@2
>>>>       c. ept3 -> i2c@3
>>>>
>>>> etc...
>>>>
>>>> This way device groups are isolated with each channel/namespace, and
>>>> instances within each device groups are also respected with specific
>>>> endpoints.
>>>>
>>>> Thanks,
>>>> Beleswar
>>>>
>>>
>>

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

[Padhi, Beleswar]

On 4/29/2026 10:23 PM, Shenwei Wang wrote:
>
>> -----Original Message-----
>> From: Mathieu Poirier <mathieu.poirier@linaro.org>
>> Sent: Wednesday, April 29, 2026 10:42 AM
>> To: Shenwei Wang <shenwei.wang@nxp.com>
>> Cc: Andrew Lunn <andrew@lunn.ch>; Padhi, Beleswar <b-padhi@ti.com>; Linus
>> Walleij <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>; Jonathan
>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof Kozlowski
>> <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn Andersson
>> <andersson@kernel.org>; Frank Li <frank.li@nxp.com>; Sascha Hauer
>> <s.hauer@pengutronix.de>; Shuah Khan <skhan@linuxfoundation.org>; linux-
>> gpio@vger.kernel.org; linux-doc@vger.kernel.org; linux-kernel@vger.kernel.org;
>> Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>> devicetree@vger.kernel.org; linux-remoteproc@vger.kernel.org;
>> imx@lists.linux.dev; linux-arm-kernel@lists.infradead.org; dl-linux-imx <linux-
>> imx@nxp.com>; Bartosz Golaszewski <brgl@bgdev.pl>
>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
>> On Tue, Apr 28, 2026 at 03:24:59PM +0000, Shenwei Wang wrote:
>>>
>>>> -----Original Message-----
>>>> From: Andrew Lunn <andrew@lunn.ch>
>>>> Sent: Monday, April 27, 2026 3:49 PM
>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>> Cc: Padhi, Beleswar <b-padhi@ti.com>; Linus Walleij
>>>> <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>; Jonathan
>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof
>>>> Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>;
>>>> Bjorn Andersson <andersson@kernel.org>; Mathieu Poirier
>>>> <mathieu.poirier@linaro.org>; Frank Li <frank.li@nxp.com>; Sascha
>>>> Hauer <s.hauer@pengutronix.de>; Shuah Khan
>>>> <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
>>>> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix
>>>> Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>>> devicetree@vger.kernel.org; linux- remoteproc@vger.kernel.org;
>>>> imx@lists.linux.dev; linux-arm- kernel@lists.infradead.org;
>>>> dl-linux-imx <linux-imx@nxp.com>; Bartosz Golaszewski
>>>> <brgl@bgdev.pl>
>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg
>>>> GPIO driver
>>>>>> struct virtio_gpio_response {
>>>>>>          __u8 status;
>>>>>>          __u8 value;
>>>>>> };
>>>>> It is the same message format. Please see the message definition
>>>> (GET_DIRECTION) below:
>>>>
>>>>> +   +-----+-----+-----+-----+-----+----+
>>>>> +   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
>>>>> +   | 1   | 2   |port |line | err | dir|
>>>>> +   +-----+-----+-----+-----+-----+----+
>>>> Sorry, but i don't see how two u8 vs six u8 are the same message format.
>>>>
>>> Some changes to the message format are necessary.
>>>
>>> Virtio uses two communication channels (virtqueues): one for requests and
>> replies, and a second one for events.
>>> In contrast, rpmsg provides only a single communication channel, so a
>>> type field is required to distinguish between different kinds of messages.
>>>
>>> Since rpmsg replies and events share the same message format, an additional
>> line is introduced to handle both cases.
>>> Finally, rpmsg supports multiple GPIO controllers, so a port field is added to
>> uniquely identify the target controller.
>>
>> I have commented on this before - RPMSG is already providing multiplexing
>> capability by way of endpoints.  There is no need for a port field.  One endpoint,
>> one GPIO controller.
>>
> You still need a way to let the remote side know which port the endpoint maps to,


About this, we only need to do this because you are defining the gpio
controller instances "statically" in the device tree. I understand gpio
nodes can act as providers, but I do not see any device referencing the
gpio nodes you are defining in the device tree. If that is the case, you
can completely remove the nodes from device tree, and "dynamically"
announce the existence of these nodes from the firmware itself
(similar to what is done for rpmsg-tty currently). In response to that
announce message, Linux could send the "ept" it allocated for the
controller. That way, Linux only cares about "ept" and there is no need
to maintain port 'idx' info anywhere in the Linux side anymore.

Thanks,
Beleswar

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

[Andrew Lunn]

> About this, we only need to do this because you are defining the gpio
> controller instances "statically" in the device tree. I understand gpio
> nodes can act as providers, but I do not see any device referencing the
> gpio nodes you are defining in the device tree.

They probably come later, and a board specific. The GPIO controllers
are probably SoC specific, so can be defined at the SoC .dtsi
level. The users are then in the board .dts files.

This is how GPIOs are typically used. Same will be true of I2C, the
SoC provides the I2C adaptor, the boards have devices on the bus,
again, described in DT.

       Andrew

     

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

[Beleswar Prasad Padhi]

On 28/04/26 00:53, Shenwei Wang wrote:
[...]
>>> +
>>> +struct rpmsg_gpio_packet {
>>> +     u8 type;        /* Message type */
>>> +     u8 cmd;         /* Command code */
>>> +     u8 port_idx;
>>> +     u8 line;
>>> +     u8 val1;
>>> +     u8 val2;
>>> +};
>>
>> Could you please document the fields in these structs (and the below ones too)?
>> From the code, it looks like while sending a message from Linux to Firmware; val1
>> and val2 are used to describe the values to set. Whereas while receiving a
>> response, val1 represents a possible error code, and val2 represents the actual
>> message of get type queries. If that is so, you might want to change the variable
>> names to be more descriptive and also use a union.
>>
> The fields in the two structs are fairly self-explanatory. Do we really need the additional comments?


val1 and val2 sounded arbitrary, that's all. If we are moving away from
that, then there is no need :)

[...]

>
>>> +     void *channel_devices[MAX_PORT_PER_CHANNEL];
>>
>> So this is technically a rpmsg endpoint (struct rpmsg_endpoint) without naming it
>> "endpoint". Every rpmsg endpoint has a reference to its parent rpmsg channel
>> (struct rpmsg_device) which represents the same information here. So we should
>> use the framework standard here.
>>
> Yes, agree to use "endpoint_devices".


I did not mean to say to just change the variable name from
"channel_devices" to "endpoint_devices". Infact you would not need to
have this field & struct anymore.

Pseudo-code:
1. Add a 'struct rpmsg_endpoint *ept' field to struct rpmsg_gpio_port
    to maintain the ept to port idx map.

2. Call port->ept = rpmsg_create_ept(rpdev,
                                                            rpmsg_gpio_channel_callback,
                                                            port, {rpdev.id.name,
                                                            RPMSG_ADDR_ANY,
                                                            RPMSG_ADDR_ANY})
    from rpmsg_gpiochip_register().

3. Send msgs from local ept in rpmsg_gpio_send_message() by:
    rpmsg_send(port->ept, msg, sizeof(*msg));

4. Get the port info in rpmsg_gpio_channel_callback() by:
    struct rpmsg_gpio_port *port = priv;

Which also eliminates the need for struct rpdev_drvdata as you can just
do rpmsg_get_rproc_node_name(rpdev) from rpmsg_gpiochip_register().


>
>> This also allows for dynamic creation and deletion of ports too! (if/when the
>> firmware supports it)
>>
>> Which means at port init time, we should make a call to
>> rpmsg_create_ept() for each port tying the same callback
>> rpmsg_gpio_channel_callback(). And based on the 'u32 src', we could identify the
>> appropriate gpio port in the callback.
>>

[...]
>>
>>> +
>>> +     girq = &gc->irq;
>>> +     gpio_irq_chip_set_chip(girq, &gpio_rpmsg_irq_chip);
>>> +     girq->parent_handler = NULL;
>>> +     girq->num_parents = 0;
>>> +     girq->parents = NULL;
>>> +     girq->chip->name = devm_kasprintf(&rpdev->dev, GFP_KERNEL, "%s-
>> gpio%d",
>>> +                                       drvdata->rproc_name,
>>> + port->idx);
>>
>> We could just re-use gc->label here...
> We also want to include the remoteproc name (for example, remoteproc-cm33-gpio0), rather than just gpio0.


Isn't it also included in the gc->label field?

gc->label = devm_kasprintf(&rpdev->dev, GFP_KERNEL, "%s-gpio%d",
+                   drvdata->rproc_name, port->idx);

[...]

>>> +}
>>> +
>>> +static int rpmsg_gpio_channel_probe(struct rpmsg_device *rpdev) {
>>> +     struct device *dev = &rpdev->dev;
>>> +     struct rpdev_drvdata *drvdata;
>>> +     struct device_node *np;
>>> +     int ret = -ENODEV;
>>> +
>>> +     if (!dev->of_node) {
>>> +             np = rpmsg_get_channel_ofnode(rpdev, rpdev->id.name);
>>> +             if (np) {
>>> +                     dev->of_node = np;
>>> +                     set_primary_fwnode(dev, of_fwnode_handle(np));
>>> +             }
>>> +             return -EPROBE_DEFER;
>>
>> I know this was asked in the v10 version also. But I don't think the answer is
>> sufficient. Should we not continue the intialization of drvdata etc if np != 0? Why
>> return a deferred probe, and let the kernel come back to it again to do the same
>> stuff with extra latency?
>>
>> We could just do:
>> if (!np) return -EPROBE_DEFER;
>> else {everything_else};
>>
> After configuring dev->of_node, it would be better to restart the driver probe process. 
> This ensures that all required resources, such as pinctrl, clocks, and power domains, are 
> properly set up if they are specified in the device node, before the probe function is invoked.


Hmm that makes sense to me... Thanks!

Thanks,
Beleswar

RE: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver

[Shenwei Wang]

> -----Original Message-----
> From: Beleswar Prasad Padhi <b-padhi@ti.com>
> Sent: Tuesday, April 28, 2026 2:25 AM
> To: Shenwei Wang <shenwei.wang@nxp.com>; Linus Walleij
> <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>; Jonathan Corbet
> <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof Kozlowski
> <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn Andersson
> <andersson@kernel.org>; Mathieu Poirier <mathieu.poirier@linaro.org>; Frank Li
> <frank.li@nxp.com>; Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Shuah Khan <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix Kernel Team
> <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; Peng Fan
> <peng.fan@nxp.com>; devicetree@vger.kernel.org; linux-
> remoteproc@vger.kernel.org; imx@lists.linux.dev; linux-arm-
> kernel@lists.infradead.org; dl-linux-imx <linux-imx@nxp.com>; Bartosz
> Golaszewski <brgl@bgdev.pl>; Andrew Lunn <andrew@lunn.ch>
> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
> On 28/04/26 00:53, Shenwei Wang wrote:
> [...]
> 
> >
> >>> +     void *channel_devices[MAX_PORT_PER_CHANNEL];
> >>
> >> So this is technically a rpmsg endpoint (struct rpmsg_endpoint)
> >> without naming it "endpoint". Every rpmsg endpoint has a reference to
> >> its parent rpmsg channel (struct rpmsg_device) which represents the
> >> same information here. So we should use the framework standard here.
> >>
> > Yes, agree to use "endpoint_devices".
> 
> 
> I did not mean to say to just change the variable name from "channel_devices" to
> "endpoint_devices". Infact you would not need to have this field & struct
> anymore.
> 
> Pseudo-code:
> 1. Add a 'struct rpmsg_endpoint *ept' field to struct rpmsg_gpio_port
>     to maintain the ept to port idx map.
> 
> 2. Call port->ept = rpmsg_create_ept(rpdev,
>                                                             rpmsg_gpio_channel_callback,
>                                                             port, {rpdev.id.name,
>                                                             RPMSG_ADDR_ANY,
>                                                             RPMSG_ADDR_ANY})
>     from rpmsg_gpiochip_register().
> 

On the Linux side, we invoke rpmsg_create_ept. What is expected from the remote system in this case?
If the remote side does not need any extra support, this would be an excellent solution.

Thanks,
Shenwei

> 3. Send msgs from local ept in rpmsg_gpio_send_message() by:
>     rpmsg_send(port->ept, msg, sizeof(*msg));
> 
> 4. Get the port info in rpmsg_gpio_channel_callback() by:
>     struct rpmsg_gpio_port *port = priv;
> 
> Which also eliminates the need for struct rpdev_drvdata as you can just do
> rpmsg_get_rproc_node_name(rpdev) from rpmsg_gpiochip_register().
> 

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

[Padhi, Beleswar]

On 4/28/2026 8:13 PM, Shenwei Wang wrote:
>
>> -----Original Message-----
>> From: Beleswar Prasad Padhi <b-padhi@ti.com>
>> Sent: Tuesday, April 28, 2026 2:25 AM
>> To: Shenwei Wang <shenwei.wang@nxp.com>; Linus Walleij
>> <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>; Jonathan Corbet
>> <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof Kozlowski
>> <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn Andersson
>> <andersson@kernel.org>; Mathieu Poirier <mathieu.poirier@linaro.org>; Frank Li
>> <frank.li@nxp.com>; Sascha Hauer <s.hauer@pengutronix.de>
>> Cc: Shuah Khan <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
>> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix Kernel Team
>> <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; Peng Fan
>> <peng.fan@nxp.com>; devicetree@vger.kernel.org; linux-
>> remoteproc@vger.kernel.org; imx@lists.linux.dev; linux-arm-
>> kernel@lists.infradead.org; dl-linux-imx <linux-imx@nxp.com>; Bartosz
>> Golaszewski <brgl@bgdev.pl>; Andrew Lunn <andrew@lunn.ch>
>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
>> On 28/04/26 00:53, Shenwei Wang wrote:
>> [...]
>>
>>>>> +     void *channel_devices[MAX_PORT_PER_CHANNEL];
>>>> So this is technically a rpmsg endpoint (struct rpmsg_endpoint)
>>>> without naming it "endpoint". Every rpmsg endpoint has a reference to
>>>> its parent rpmsg channel (struct rpmsg_device) which represents the
>>>> same information here. So we should use the framework standard here.
>>>>
>>> Yes, agree to use "endpoint_devices".
>>
>> I did not mean to say to just change the variable name from "channel_devices" to
>> "endpoint_devices". Infact you would not need to have this field & struct
>> anymore.
>>
>> Pseudo-code:
>> 1. Add a 'struct rpmsg_endpoint *ept' field to struct rpmsg_gpio_port
>>      to maintain the ept to port idx map.
>>
>> 2. Call port->ept = rpmsg_create_ept(rpdev,
>>                                                              rpmsg_gpio_channel_callback,
>>                                                              port, {rpdev.id.name,
>>                                                              RPMSG_ADDR_ANY,
>>                                                              RPMSG_ADDR_ANY})
>>      from rpmsg_gpiochip_register().
>>
> On the Linux side, we invoke rpmsg_create_ept. What is expected from the remote system in this case?


Nothing extra in my opinion. rpmsg_create_ept() just creates a dynamic
local endpoint address for Linux's usage. The firmware just has to make
sure to reply to the same endpoint address where it received the
message. This should already be in place IMO, because currently you are
sending all messages in the default endpoint (rpdev->ept) which is also
dynamic[1] and is created when the channel is created. And you receive
the responses correctly. (Unless you have hard-coded the default ept
address in the firmware)

[1]: 
https://github.com/torvalds/linux/blob/master/drivers/rpmsg/rpmsg_core.c#L480
(chinfo.src is RPMSG_ADDR_ANY)

Thanks,
Beleswar

> If the remote side does not need any extra support, this would be an excellent solution.
>
> Thanks,
> Shenwei
>
>> 3. Send msgs from local ept in rpmsg_gpio_send_message() by:
>>      rpmsg_send(port->ept, msg, sizeof(*msg));
>>
>> 4. Get the port info in rpmsg_gpio_channel_callback() by:
>>      struct rpmsg_gpio_port *port = priv;
>>
>> Which also eliminates the need for struct rpdev_drvdata as you can just do
>> rpmsg_get_rproc_node_name(rpdev) from rpmsg_gpiochip_register().
>>

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

[Shenwei Wang]

> -----Original Message-----
> From: Padhi, Beleswar <b-padhi@ti.com>
> Sent: Tuesday, April 28, 2026 10:11 AM
> To: Shenwei Wang <shenwei.wang@nxp.com>; Linus Walleij
> <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>; Jonathan Corbet
> <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof Kozlowski
> <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn Andersson
> <andersson@kernel.org>; Mathieu Poirier <mathieu.poirier@linaro.org>; Frank Li
> <frank.li@nxp.com>; Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Shuah Khan <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix Kernel Team
> <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; Peng Fan
> <peng.fan@nxp.com>; devicetree@vger.kernel.org; linux-
> remoteproc@vger.kernel.org; imx@lists.linux.dev; linux-arm-
> kernel@lists.infradead.org; dl-linux-imx <linux-imx@nxp.com>; Bartosz
> Golaszewski <brgl@bgdev.pl>; Andrew Lunn <andrew@lunn.ch>
> Subject: Re: [EXT] Re: [PATCH v13 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
>
>
> On 4/28/2026 8:13 PM, Shenwei Wang wrote:
> >
> >> -----Original Message-----
> >> From: Beleswar Prasad Padhi <b-padhi@ti.com>
> >> Sent: Tuesday, April 28, 2026 2:25 AM
> >> To: Shenwei Wang <shenwei.wang@nxp.com>; Linus Walleij
> >> <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>; Jonathan
> >> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof
> >> Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>;
> >> Bjorn Andersson <andersson@kernel.org>; Mathieu Poirier
> >> <mathieu.poirier@linaro.org>; Frank Li <frank.li@nxp.com>; Sascha
> >> Hauer <s.hauer@pengutronix.de>
> >> Cc: Shuah Khan <skhan@linuxfoundation.org>;
> >> linux-gpio@vger.kernel.org; linux- doc@vger.kernel.org;
> >> linux-kernel@vger.kernel.org; Pengutronix Kernel Team
> >> <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; Peng Fan
> >> <peng.fan@nxp.com>; devicetree@vger.kernel.org; linux-
> >> remoteproc@vger.kernel.org; imx@lists.linux.dev; linux-arm-
> >> kernel@lists.infradead.org; dl-linux-imx <linux-imx@nxp.com>; Bartosz
> >> Golaszewski <brgl@bgdev.pl>; Andrew Lunn <andrew@lunn.ch>
> >> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg
> >> GPIO driver On 28/04/26 00:53, Shenwei Wang wrote:
> >> [...]
> >>
> >>>>> +     void *channel_devices[MAX_PORT_PER_CHANNEL];
> >>>> So this is technically a rpmsg endpoint (struct rpmsg_endpoint)
> >>>> without naming it "endpoint". Every rpmsg endpoint has a reference
> >>>> to its parent rpmsg channel (struct rpmsg_device) which represents
> >>>> the same information here. So we should use the framework standard here.
> >>>>
> >>> Yes, agree to use "endpoint_devices".
> >>
> >> I did not mean to say to just change the variable name from
> >> "channel_devices" to "endpoint_devices". Infact you would not need to
> >> have this field & struct anymore.
> >>
> >> Pseudo-code:
> >> 1. Add a 'struct rpmsg_endpoint *ept' field to struct rpmsg_gpio_port
> >>      to maintain the ept to port idx map.
> >>
> >> 2. Call port->ept = rpmsg_create_ept(rpdev,
> >>                                                              rpmsg_gpio_channel_callback,
> >>                                                              port, {rpdev.id.name,
> >>                                                              RPMSG_ADDR_ANY,
> >>                                                              RPMSG_ADDR_ANY})
> >>      from rpmsg_gpiochip_register().
> >>
> > On the Linux side, we invoke rpmsg_create_ept. What is expected from the
> remote system in this case?
>
>
> Nothing extra in my opinion. rpmsg_create_ept() just creates a dynamic local
> endpoint address for Linux's usage. The firmware just has to make sure to reply
> to the same endpoint address where it received the message. This should already
> be in place IMO, because currently you are sending all messages in the default

Since rpmsg_create_ept creates a new local endpoint address on the Linux side, how is
the remote system expected to learn and use this new address for communication if no
additional logic is added on the remote side?

Is this handled automatically by the rpmsg stack software, or does it require explicit support
on the remote system to exchange and track endpoint addresses?

Thanks,
Shenwei

> endpoint (rpdev->ept) which is also dynamic[1] and is created when the channel
> is created. And you receive the responses correctly. (Unless you have hard-coded
> the default ept address in the firmware)
>
> [1]:
> https://github.co/
> m%2Ftorvalds%2Flinux%2Fblob%2Fmaster%2Fdrivers%2Frpmsg%2Frpmsg_core.
> c%23L480&data=05%7C02%7Cshenwei.wang%40nxp.com%7C4ec06bf01bb14dd
> 2625708dea5387471%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6
> 39129859078622527%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd
> WUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%
> 3D%7C0%7C%7C%7C&sdata=OUmjqOdWqiXSTjPDv1TUvrjKP1YTx9ji44SdGlIR2n
> Q%3D&reserved=0
> (chinfo.src is RPMSG_ADDR_ANY)
>
> Thanks,
> Beleswar
>
> > If the remote side does not need any extra support, this would be an excellent
> solution.
> >
> > Thanks,
> > Shenwei
> >
> >> 3. Send msgs from local ept in rpmsg_gpio_send_message() by:
> >>      rpmsg_send(port->ept, msg, sizeof(*msg));
> >>
> >> 4. Get the port info in rpmsg_gpio_channel_callback() by:
> >>      struct rpmsg_gpio_port *port = priv;
> >>
> >> Which also eliminates the need for struct rpdev_drvdata as you can
> >> just do
> >> rpmsg_get_rproc_node_name(rpdev) from rpmsg_gpiochip_register().
> >>

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

[Padhi, Beleswar]

On 4/28/2026 9:01 PM, Shenwei Wang wrote:
>
>> -----Original Message-----
>> From: Padhi, Beleswar <b-padhi@ti.com>
>> Sent: Tuesday, April 28, 2026 10:11 AM
>> To: Shenwei Wang <shenwei.wang@nxp.com>; Linus Walleij
>> <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>; Jonathan Corbet
>> <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof Kozlowski
>> <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn Andersson
>> <andersson@kernel.org>; Mathieu Poirier <mathieu.poirier@linaro.org>; Frank Li
>> <frank.li@nxp.com>; Sascha Hauer <s.hauer@pengutronix.de>
>> Cc: Shuah Khan <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
>> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix Kernel Team
>> <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; Peng Fan
>> <peng.fan@nxp.com>; devicetree@vger.kernel.org; linux-
>> remoteproc@vger.kernel.org; imx@lists.linux.dev; linux-arm-
>> kernel@lists.infradead.org; dl-linux-imx <linux-imx@nxp.com>; Bartosz
>> Golaszewski <brgl@bgdev.pl>; Andrew Lunn <andrew@lunn.ch>
>> Subject: Re: [EXT] Re: [PATCH v13 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
>>
>>
>> On 4/28/2026 8:13 PM, Shenwei Wang wrote:
>>>> -----Original Message-----
>>>> From: Beleswar Prasad Padhi <b-padhi@ti.com>
>>>> Sent: Tuesday, April 28, 2026 2:25 AM
>>>> To: Shenwei Wang <shenwei.wang@nxp.com>; Linus Walleij
>>>> <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>; Jonathan
>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof
>>>> Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>;
>>>> Bjorn Andersson <andersson@kernel.org>; Mathieu Poirier
>>>> <mathieu.poirier@linaro.org>; Frank Li <frank.li@nxp.com>; Sascha
>>>> Hauer <s.hauer@pengutronix.de>
>>>> Cc: Shuah Khan <skhan@linuxfoundation.org>;
>>>> linux-gpio@vger.kernel.org; linux- doc@vger.kernel.org;
>>>> linux-kernel@vger.kernel.org; Pengutronix Kernel Team
>>>> <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; Peng Fan
>>>> <peng.fan@nxp.com>; devicetree@vger.kernel.org; linux-
>>>> remoteproc@vger.kernel.org; imx@lists.linux.dev; linux-arm-
>>>> kernel@lists.infradead.org; dl-linux-imx <linux-imx@nxp.com>; Bartosz
>>>> Golaszewski <brgl@bgdev.pl>; Andrew Lunn <andrew@lunn.ch>
>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg
>>>> GPIO driver On 28/04/26 00:53, Shenwei Wang wrote:
>>>> [...]
>>>>
>>>>>>> +     void *channel_devices[MAX_PORT_PER_CHANNEL];
>>>>>> So this is technically a rpmsg endpoint (struct rpmsg_endpoint)
>>>>>> without naming it "endpoint". Every rpmsg endpoint has a reference
>>>>>> to its parent rpmsg channel (struct rpmsg_device) which represents
>>>>>> the same information here. So we should use the framework standard here.
>>>>>>
>>>>> Yes, agree to use "endpoint_devices".
>>>> I did not mean to say to just change the variable name from
>>>> "channel_devices" to "endpoint_devices". Infact you would not need to
>>>> have this field & struct anymore.
>>>>
>>>> Pseudo-code:
>>>> 1. Add a 'struct rpmsg_endpoint *ept' field to struct rpmsg_gpio_port
>>>>       to maintain the ept to port idx map.
>>>>
>>>> 2. Call port->ept = rpmsg_create_ept(rpdev,
>>>>                                                               rpmsg_gpio_channel_callback,
>>>>                                                               port, {rpdev.id.name,
>>>>                                                               RPMSG_ADDR_ANY,
>>>>                                                               RPMSG_ADDR_ANY})
>>>>       from rpmsg_gpiochip_register().
>>>>
>>> On the Linux side, we invoke rpmsg_create_ept. What is expected from the
>> remote system in this case?
>>
>>
>> Nothing extra in my opinion. rpmsg_create_ept() just creates a dynamic local
>> endpoint address for Linux's usage. The firmware just has to make sure to reply
>> to the same endpoint address where it received the message. This should already
>> be in place IMO, because currently you are sending all messages in the default
> Since rpmsg_create_ept creates a new local endpoint address on the Linux side, how is
> the remote system expected to learn and use this new address for communication if no
> additional logic is added on the remote side?


Remote side learns the endpoint when it receives any message from Linux
from the dynamic endpoint.

Lets say rpmsg_create_ept() allocates a dynamic local ept of 1026. When
you send the message from this endpoint, the standard rpmsg header
would have:

     85 struct rpmsg_hdr {
     86         __rpmsg32 src; // 1026
     87         __rpmsg32 dst; // rpdev->dst (e.g. 400)
     88         __rpmsg32 reserved;
     89         __rpmsg16 len;
     90         __rpmsg16 flags;
     91         u8 data[];
     92 } __packed;

Remote side tracks the dynamic endpoint by reading src = 1026. And while
sending the response it fills the header as:

     85 struct rpmsg_hdr {
     86         __rpmsg32 src; // 400
     87         __rpmsg32 dst; // 1026
     88         __rpmsg32 reserved;
     89         __rpmsg16 len;
     90         __rpmsg16 flags;
     91         u8 data[];
     92 } __packed;

Note: Remote firmware can also send messages from dynamically created
endpoints on its side, and Linux can learn those in the same manner. The
dynamic endpoint address is passed to the callback as 'u32 src'. So you
could pass on the 'src' from rpmsg_gpio_channel_callback() to
rpmsg_gpio_send_message() as 'dst' and call
rpmsg_sendto(port->ept, msg, sizeof(*msg), dst) to reply to the dynamic
endpoint on firmware's side.

Thanks,
Beleswar

>
> Is this handled automatically by the rpmsg stack software, or does it require explicit support
> on the remote system to exchange and track endpoint addresses?
>
> Thanks,
> Shenwei
>
>> endpoint (rpdev->ept) which is also dynamic[1] and is created when the channel
>> is created. And you receive the responses correctly. (Unless you have hard-coded
>> the default ept address in the firmware)
>>
>> [1]:
>> https://github.co/
>> m%2Ftorvalds%2Flinux%2Fblob%2Fmaster%2Fdrivers%2Frpmsg%2Frpmsg_core.
>> c%23L480&data=05%7C02%7Cshenwei.wang%40nxp.com%7C4ec06bf01bb14dd
>> 2625708dea5387471%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6
>> 39129859078622527%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd
>> WUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%
>> 3D%7C0%7C%7C%7C&sdata=OUmjqOdWqiXSTjPDv1TUvrjKP1YTx9ji44SdGlIR2n
>> Q%3D&reserved=0
>> (chinfo.src is RPMSG_ADDR_ANY)
>>
>> Thanks,
>> Beleswar
>>
>>> If the remote side does not need any extra support, this would be an excellent
>> solution.
>>> Thanks,
>>> Shenwei
>>>
>>>> 3. Send msgs from local ept in rpmsg_gpio_send_message() by:
>>>>       rpmsg_send(port->ept, msg, sizeof(*msg));
>>>>
>>>> 4. Get the port info in rpmsg_gpio_channel_callback() by:
>>>>       struct rpmsg_gpio_port *port = priv;
>>>>
>>>> Which also eliminates the need for struct rpdev_drvdata as you can
>>>> just do
>>>> rpmsg_get_rproc_node_name(rpdev) from rpmsg_gpiochip_register().
>>>>

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

[Shenwei Wang]

> -----Original Message-----
> From: Padhi, Beleswar <b-padhi@ti.com>
> Sent: Tuesday, April 28, 2026 10:53 AM
> To: Shenwei Wang <shenwei.wang@nxp.com>; Linus Walleij
> <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>; Jonathan Corbet
> <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof Kozlowski
> <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn Andersson
> <andersson@kernel.org>; Mathieu Poirier <mathieu.poirier@linaro.org>; Frank Li
> <frank.li@nxp.com>; Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Shuah Khan <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix Kernel Team
> <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; Peng Fan
> <peng.fan@nxp.com>; devicetree@vger.kernel.org; linux-
> remoteproc@vger.kernel.org; imx@lists.linux.dev; linux-arm-
> kernel@lists.infradead.org; dl-linux-imx <linux-imx@nxp.com>; Bartosz
> Golaszewski <brgl@bgdev.pl>; Andrew Lunn <andrew@lunn.ch>
> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
> >>
> >> Nothing extra in my opinion. rpmsg_create_ept() just creates a
> >> dynamic local endpoint address for Linux's usage. The firmware just
> >> has to make sure to reply to the same endpoint address where it
> >> received the message. This should already be in place IMO, because
> >> currently you are sending all messages in the default
> > Since rpmsg_create_ept creates a new local endpoint address on the
> > Linux side, how is the remote system expected to learn and use this
> > new address for communication if no additional logic is added on the remote
> side?
> 
> 
> Remote side learns the endpoint when it receives any message from Linux from
> the dynamic endpoint.
> 
> Lets say rpmsg_create_ept() allocates a dynamic local ept of 1026. When you
> send the message from this endpoint, the standard rpmsg header would have:
> 
>      85 struct rpmsg_hdr {
>      86         __rpmsg32 src; // 1026
>      87         __rpmsg32 dst; // rpdev->dst (e.g. 400)
>      88         __rpmsg32 reserved;
>      89         __rpmsg16 len;
>      90         __rpmsg16 flags;
>      91         u8 data[];
>      92 } __packed;
> 
> Remote side tracks the dynamic endpoint by reading src = 1026. And while
> sending the response it fills the header as:
> 
>      85 struct rpmsg_hdr {
>      86         __rpmsg32 src; // 400
>      87         __rpmsg32 dst; // 1026
>      88         __rpmsg32 reserved;
>      89         __rpmsg16 len;
>      90         __rpmsg16 flags;
>      91         u8 data[];
>      92 } __packed;
> 

This explains how reply messages work in this scenario: the remote side can simply send 
the response back to the source address of the incoming message.

How does this work for notification messages initiated by the remote side? Should the remote 
system need to add additional logic to track the source address based on the GPIO instance?

Thanks,
Shenwei

> Note: Remote firmware can also send messages from dynamically created
> endpoints on its side, and Linux can learn those in the same manner. The dynamic
> endpoint address is passed to the callback as 'u32 src'. So you could pass on the
> 'src' from rpmsg_gpio_channel_callback() to
> rpmsg_gpio_send_message() as 'dst' and call rpmsg_sendto(port->ept, msg,
> sizeof(*msg), dst) to reply to the dynamic endpoint on firmware's side.
> 
> Thanks,
> Beleswar
> 
> >
> > Is this handled automatically by the rpmsg stack software, or does it
> > require explicit support on the remote system to exchange and track endpoint
> addresses?
> >
> > Thanks,
> > Shenwei
> >
> >> endpoint (rpdev->ept) which is also dynamic[1] and is created when
> >> the channel is created. And you receive the responses correctly.
> >> (Unless you have hard-coded the default ept address in the firmware)
> >>
> >> [1]:
> >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
> >>
> hub.co%2F&data=05%7C02%7Cshenwei.wang%40nxp.com%7C057bf7f0976749
> 5bcc3
> >>
> 108dea53e43f7%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63912
> 98840
> >>
> 26686251%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiI
> wLjAu
> >>
> MDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C
> %7C
> >>
> &sdata=iSxGWEvYSyu29loP9b1R2bw8bvwR7pbzQ7D%2FGeB%2BUYE%3D&reser
> ved=0
> >>
> m%2Ftorvalds%2Flinux%2Fblob%2Fmaster%2Fdrivers%2Frpmsg%2Frpmsg_core.
> >>
> c%23L480&data=05%7C02%7Cshenwei.wang%40nxp.com%7C4ec06bf01bb14dd
> >>
> 2625708dea5387471%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6
> >>
> 39129859078622527%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd
> >>
> WUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%
> >>
> 3D%7C0%7C%7C%7C&sdata=OUmjqOdWqiXSTjPDv1TUvrjKP1YTx9ji44SdGlIR2n
> >> Q%3D&reserved=0
> >> (chinfo.src is RPMSG_ADDR_ANY)
> >>
> >> Thanks,
> >> Beleswar
> >>
> >>> If the remote side does not need any extra support, this would be an
> >>> excellent
> >> solution.
> >>> Thanks,
> >>> Shenwei
> >>>
> >>>> 3. Send msgs from local ept in rpmsg_gpio_send_message() by:
> >>>>       rpmsg_send(port->ept, msg, sizeof(*msg));
> >>>>
> >>>> 4. Get the port info in rpmsg_gpio_channel_callback() by:
> >>>>       struct rpmsg_gpio_port *port = priv;
> >>>>
> >>>> Which also eliminates the need for struct rpdev_drvdata as you can
> >>>> just do
> >>>> rpmsg_get_rproc_node_name(rpdev) from rpmsg_gpiochip_register().
> >>>>

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

[Padhi, Beleswar]

On 4/28/2026 10:06 PM, Shenwei Wang wrote:
>
>> -----Original Message-----
>> From: Padhi, Beleswar <b-padhi@ti.com>
>> Sent: Tuesday, April 28, 2026 10:53 AM
>> To: Shenwei Wang <shenwei.wang@nxp.com>; Linus Walleij
>> <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>; Jonathan Corbet
>> <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof Kozlowski
>> <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn Andersson
>> <andersson@kernel.org>; Mathieu Poirier <mathieu.poirier@linaro.org>; Frank Li
>> <frank.li@nxp.com>; Sascha Hauer <s.hauer@pengutronix.de>
>> Cc: Shuah Khan <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
>> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix Kernel Team
>> <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; Peng Fan
>> <peng.fan@nxp.com>; devicetree@vger.kernel.org; linux-
>> remoteproc@vger.kernel.org; imx@lists.linux.dev; linux-arm-
>> kernel@lists.infradead.org; dl-linux-imx <linux-imx@nxp.com>; Bartosz
>> Golaszewski <brgl@bgdev.pl>; Andrew Lunn <andrew@lunn.ch>
>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
>>>> Nothing extra in my opinion. rpmsg_create_ept() just creates a
>>>> dynamic local endpoint address for Linux's usage. The firmware just
>>>> has to make sure to reply to the same endpoint address where it
>>>> received the message. This should already be in place IMO, because
>>>> currently you are sending all messages in the default
>>> Since rpmsg_create_ept creates a new local endpoint address on the
>>> Linux side, how is the remote system expected to learn and use this
>>> new address for communication if no additional logic is added on the remote
>> side?
>>
>>
>> Remote side learns the endpoint when it receives any message from Linux from
>> the dynamic endpoint.
>>
>> Lets say rpmsg_create_ept() allocates a dynamic local ept of 1026. When you
>> send the message from this endpoint, the standard rpmsg header would have:
>>
>>       85 struct rpmsg_hdr {
>>       86         __rpmsg32 src; // 1026
>>       87         __rpmsg32 dst; // rpdev->dst (e.g. 400)
>>       88         __rpmsg32 reserved;
>>       89         __rpmsg16 len;
>>       90         __rpmsg16 flags;
>>       91         u8 data[];
>>       92 } __packed;
>>
>> Remote side tracks the dynamic endpoint by reading src = 1026. And while
>> sending the response it fills the header as:
>>
>>       85 struct rpmsg_hdr {
>>       86         __rpmsg32 src; // 400
>>       87         __rpmsg32 dst; // 1026
>>       88         __rpmsg32 reserved;
>>       89         __rpmsg16 len;
>>       90         __rpmsg16 flags;
>>       91         u8 data[];
>>       92 } __packed;
>>
> This explains how reply messages work in this scenario: the remote side can simply send
> the response back to the source address of the incoming message.
>
> How does this work for notification messages initiated by the remote side? Should the remote
> system need to add additional logic to track the source address based on the GPIO instance?


You should already have the tracking logic in firmware. How else are you
sending the notification messages from firmware with your current v13
implementation? Are you assuming the channel address to be always the
same? If so, this is a bug and should be fixed in firmware because the
address is generated dynamically. For example, if another core announces
its name service first, then the channel address for your core would be
different and the functionality would break.

Instead, you should have a map of ept to port idx in the firmware side
when you receive a message from Linux (just like we would maintain it
in struct rpmsg_gpio_port in Linux too).

Thanks,
Beleswar

[...]

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

[Shenwei Wang]

> -----Original Message-----
> From: Padhi, Beleswar <b-padhi@ti.com>
> Sent: Wednesday, April 29, 2026 9:36 AM
> To: Shenwei Wang <shenwei.wang@nxp.com>; Linus Walleij
> <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>; Jonathan Corbet
> <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof Kozlowski
> <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn Andersson
> <andersson@kernel.org>; Mathieu Poirier <mathieu.poirier@linaro.org>; Frank Li
> <frank.li@nxp.com>; Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Shuah Khan <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix Kernel Team
> <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; Peng Fan
> <peng.fan@nxp.com>; devicetree@vger.kernel.org; linux-
> remoteproc@vger.kernel.org; imx@lists.linux.dev; linux-arm-
> kernel@lists.infradead.org; dl-linux-imx <linux-imx@nxp.com>; Bartosz
> Golaszewski <brgl@bgdev.pl>; Andrew Lunn <andrew@lunn.ch>
> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
> On 4/28/2026 10:06 PM, Shenwei Wang wrote:
> >
> >> -----Original Message-----
> >> From: Padhi, Beleswar <b-padhi@ti.com>
> >> Sent: Tuesday, April 28, 2026 10:53 AM
> >> To: Shenwei Wang <shenwei.wang@nxp.com>; Linus Walleij
> >> <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>; Jonathan
> >> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof
> >> Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>;
> >> Bjorn Andersson <andersson@kernel.org>; Mathieu Poirier
> >> <mathieu.poirier@linaro.org>; Frank Li <frank.li@nxp.com>; Sascha
> >> Hauer <s.hauer@pengutronix.de>
> >> Cc: Shuah Khan <skhan@linuxfoundation.org>;
> >> linux-gpio@vger.kernel.org; linux- doc@vger.kernel.org;
> >> linux-kernel@vger.kernel.org; Pengutronix Kernel Team
> >> <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; Peng Fan
> >> <peng.fan@nxp.com>; devicetree@vger.kernel.org; linux-
> >> remoteproc@vger.kernel.org; imx@lists.linux.dev; linux-arm-
> >> kernel@lists.infradead.org; dl-linux-imx <linux-imx@nxp.com>; Bartosz
> >> Golaszewski <brgl@bgdev.pl>; Andrew Lunn <andrew@lunn.ch>
> >> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg
> >> GPIO driver
> >>>> Nothing extra in my opinion. rpmsg_create_ept() just creates a
> >>>> dynamic local endpoint address for Linux's usage. The firmware just
> >>>> has to make sure to reply to the same endpoint address where it
> >>>> received the message. This should already be in place IMO, because
> >>>> currently you are sending all messages in the default
> >>> Since rpmsg_create_ept creates a new local endpoint address on the
> >>> Linux side, how is the remote system expected to learn and use this
> >>> new address for communication if no additional logic is added on the
> >>> remote
> >> side?
> >>
> >>
> >> Remote side learns the endpoint when it receives any message from
> >> Linux from the dynamic endpoint.
> >>
> >> Lets say rpmsg_create_ept() allocates a dynamic local ept of 1026.
> >> When you send the message from this endpoint, the standard rpmsg header
> would have:
> >>
> >>       85 struct rpmsg_hdr {
> >>       86         __rpmsg32 src; // 1026
> >>       87         __rpmsg32 dst; // rpdev->dst (e.g. 400)
> >>       88         __rpmsg32 reserved;
> >>       89         __rpmsg16 len;
> >>       90         __rpmsg16 flags;
> >>       91         u8 data[];
> >>       92 } __packed;
> >>
> >> Remote side tracks the dynamic endpoint by reading src = 1026. And
> >> while sending the response it fills the header as:
> >>
> >>       85 struct rpmsg_hdr {
> >>       86         __rpmsg32 src; // 400
> >>       87         __rpmsg32 dst; // 1026
> >>       88         __rpmsg32 reserved;
> >>       89         __rpmsg16 len;
> >>       90         __rpmsg16 flags;
> >>       91         u8 data[];
> >>       92 } __packed;
> >>
> > This explains how reply messages work in this scenario: the remote
> > side can simply send the response back to the source address of the incoming
> message.
> >
> > How does this work for notification messages initiated by the remote
> > side? Should the remote system need to add additional logic to track the source
> address based on the GPIO instance?
> 
> 
> You should already have the tracking logic in firmware. How else are you sending
> the notification messages from firmware with your current v13 implementation?
> Are you assuming the channel address to be always the same? If so, this is a bug
> and should be fixed in firmware because the address is generated dynamically.
> For example, if another core announces its name service first, then the channel
> address for your core would be different and the functionality would break.
> 

In the v13 implementation, all GPIO instances share the default endpoint. As a result, the 
firmware does not need to track the port index, since the port index is embedded in each 
message.

With the new approach you proposed, we would create a separate endpoint for each GPIO 
controller. The GPIO controller information is derived from the corresponding DTS node, and 
the port index continues to be embedded in every message exchanged with the remote side, in 
accordance with the current message protocol.

However, in this model, the firmware still needs to add logic to track the mapping between the 
port index and the corresponding endpoint for notifications initiated by the remote side. Am I 
understanding this correctly?

Thanks,
Shenwei

> Instead, you should have a map of ept to port idx in the firmware side when you
> receive a message from Linux (just like we would maintain it in struct
> rpmsg_gpio_port in Linux too).
> 
> Thanks,
> Beleswar
> 
> [...]

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

[Andrew Lunn]

> Remote side learns the endpoint when it receives any message from Linux
> from the dynamic endpoint.
> 
> Lets say rpmsg_create_ept() allocates a dynamic local ept of 1026. When
> you send the message from this endpoint, the standard rpmsg header
> would have:
> 
>     85 struct rpmsg_hdr {
>     86         __rpmsg32 src; // 1026
>     87         __rpmsg32 dst; // rpdev->dst (e.g. 400)
>     88         __rpmsg32 reserved;
>     89         __rpmsg16 len;
>     90         __rpmsg16 flags;
>     91         u8 data[];
>     92 } __packed;
> 
> Remote side tracks the dynamic endpoint by reading src = 1026. And while
> sending the response it fills the header as:

I've never used rpmsg, so this might be a FAQ. How does the remote
side know what the endpoint is to be used for? Here we are talking
about GPIO. But the same hardware implements I2C, and a few other
things. How do we indicate this endpoint is for GPIO?

Maybe also related, this hardware also supports a number of GPIO
controllers. There has been some argument about if one endpoint should
support multiple GPIO controllers. Or, like gpio-virtio, one endpoint
represents one GPIO controller, and you instantiate multiple
endpoints, one per controller. How can you tell the different
instances of GPIO endpoints apart when they are dynamically created?

   Andrew

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

[Padhi, Beleswar]

On 4/28/2026 11:35 PM, Andrew Lunn wrote:
>> Remote side learns the endpoint when it receives any message from Linux
>> from the dynamic endpoint.
>>
>> Lets say rpmsg_create_ept() allocates a dynamic local ept of 1026. When
>> you send the message from this endpoint, the standard rpmsg header
>> would have:
>>
>>      85 struct rpmsg_hdr {
>>      86         __rpmsg32 src; // 1026
>>      87         __rpmsg32 dst; // rpdev->dst (e.g. 400)
>>      88         __rpmsg32 reserved;
>>      89         __rpmsg16 len;
>>      90         __rpmsg16 flags;
>>      91         u8 data[];
>>      92 } __packed;
>>
>> Remote side tracks the dynamic endpoint by reading src = 1026. And while
>> sending the response it fills the header as:
> I've never used rpmsg, so this might be a FAQ. How does the remote
> side know what the endpoint is to be used for? Here we are talking
> about GPIO. But the same hardware implements I2C, and a few other
> things. How do we indicate this endpoint is for GPIO?


That's where the channel level isolation helps. GPIO ports are announced
over "rpmsg-io" channel (parent of endpoint), i2c devices would be
announced over "rpmsg-i2c" channel. The default epts in those channels
would have separate addresses (e.g. 0xd for rpmsg-io and 0xe for
rpmsg-i2c). The remote side would have bound a gpio_handling callback
on addr 0xd and a i2c_handling callback on addr 0xe while doing the
channel announcement. So while sending a GPIO msg from Linux, we
should direct it to 0xd dst endpoint, and for sending a i2c message, we
should direct it to 0xe dst endpoint (src ept can be anything). And without
any extra effort, messages sent from dynamic epts at Linux land in the
appropriate handler at remote even for separate device types.

>
> Maybe also related, this hardware also supports a number of GPIO
> controllers. There has been some argument about if one endpoint should
> support multiple GPIO controllers.


IMO no...

>   Or, like gpio-virtio, one endpoint
> represents one GPIO controller, and you instantiate multiple
> endpoints, one per controller.


Yes, this is what I am suggesting in the review of this version.
Basically there should be one rpmsg channel per device type
(e.g. gpio/i2c), and multiple rpmsg endpoints in one channel
representing each instance of the device (e.g. gpio1, gpio2 etc.)

>   How can you tell the different
> instances of GPIO endpoints apart when they are dynamically created?


Well by 2 ways:
1. We can maintain a map of the dynamically created ept and its
     corresponding instance number.This is useful while sending a message
     for a particular instance.
2. rpmsg_create_ept() takes a private data argument, so we just bind the
     per-instance data (struct rpmsg_gpio_port * in this case) to the ept.
     This is useful while receiving a message for a particular instance.

I have suggested an implementation for the same here:
https://lore.kernel.org/all/29485742-6e49-482e-b73d-228295daaeec@ti.com/

Thanks,
Beleswar

[PATCH v13 4/4] arm64: dts: imx8ulp: Add rpmsg node under imx_rproc

[Shenwei Wang]

Add the RPMSG bus node along with its GPIO subnodes to the device
tree.

Enable remote device communication and GPIO control via RPMSG on
the i.MX platform.

Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com>
---
 arch/arm64/boot/dts/freescale/imx8ulp.dtsi | 25 ++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
index 1de3ad60c6aa..f1b984eb1203 100644
--- a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
@@ -190,6 +190,31 @@ scmi_sensor: protocol@15 {
 	cm33: remoteproc-cm33 {
 		compatible = "fsl,imx8ulp-cm33";
 		status = "disabled";
+
+		rpmsg {
+			rpmsg-io {
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				rpmsg_gpioa: gpio@0 {
+					compatible = "rpmsg-gpio";
+					reg = <0>;
+					gpio-controller;
+					#gpio-cells = <2>;
+					#interrupt-cells = <2>;
+					interrupt-controller;
+				};
+
+				rpmsg_gpiob: gpio@1 {
+					compatible = "rpmsg-gpio";
+					reg = <1>;
+					gpio-controller;
+					#gpio-cells = <2>;
+					#interrupt-cells = <2>;
+					interrupt-controller;
+				};
+			};
+		};
 	};
 
 	soc: soc@0 {
-- 
2.43.0

Re: [PATCH v13 0/4] Enable Remote GPIO over RPMSG on i.MX Platform

[Mathieu Poirier]

Once again Andrew Lunn was left out.

On Wed, 22 Apr 2026 at 15:29, Shenwei Wang <shenwei.wang@nxp.com> wrote:
>
> Support the remote devices on the remote processor via the RPMSG bus on
> i.MX platform.
>
> Changes in v13:
>  - drop the support for legacy NXP firmware.
>  - remove the fixed_up hooks from the rpmsg gpio driver.
>  - code cleanup.
>
> Changes in v12:
>  - Fixed the "underline" warning reported by Randy.
>
> Changes in v11:
>  - Expand RPMSG for the first time per Shuah's review comment.
>
> Changes in v10:
>  - Update gpio-rpmsg.rst according to Daniel Baluta's review comments.
>  - Add a kernel CONFIG for fixed up handlers and only enable it on
>    i.MX products.
>  - Fixed bugs reported by kernel test robot.
>
> Changes in v9:
>  - Reuse the gpio-virtio design for command and IRQ type definitions.
>  - Remove msg_id, version, and vendor fields from the generic protocol.
>  - Add fixed-up handlers to support legacy firmware.
>
> Changes in v8:
>  - Add "depends on REMOTEPROC" in Kconfig to fix the build error reported
>    by the kernel test robot.
>  - Move the .rst patch before the .yaml patch.
>  - Handle the "ngpios" DT property based on Andrew's feedback.
>
> Changes in v7:
>  - Reworked the driver to use the rpmsg_driver framework instead of
>    platform_driver, based on feedback from Bjorn and Arnaud.
>  - Updated gpio-rpmsg.yaml and imx_rproc.yaml according to comments from
>    Rob and Arnaud.
>  - Further refinements to gpio-rpmsg.yaml per Arnaud's feedback.
>
> Changes in v6:
>  - make the driver more generic with the actions below:
>      rename the driver file to gpio-rpmsg.c
>      remove the imx related info in the function and variable names
>      rename the imx_rpmsg.h to rpdev_info.h
>      create a gpio-rpmsg.yaml and refer it in imx_rproc.yaml
>  - update the gpio-rpmsg.rst according to the feedback from Andrew and
>    move the source file to driver-api/gpio
>  - fix the bug reported by Zhongqiu Han
>  - remove the I2C related info
>
> Changes in v5:
>  - move the gpio-rpmsg.rst from admin-guide to staging directory after
>    discussion with Randy Dunlap.
>  - add include files with some code improvements per Bartosz's comments.
>
> Changes in v4:
>  - add a documentation to describe the transport protocol per Andrew's
>    comments.
>  - add a new handler to get the gpio direction.
>
> Changes in v3:
>  - fix various format issue and return value check per Peng 's review
>    comments.
>  - add the logic to also populate the subnodes which are not in the
>    device map per Arnaud's request. (in imx_rproc.c)
>  - update the yaml per Frank's review comments.
>
> Changes in v2:
>  - re-implemented the gpio driver per Linus Walleij's feedback by using
>    GPIOLIB_IRQCHIP helper library.
>  - fix various format issue per Mathieu/Peng 's review comments.
>  - update the yaml doc per Rob's feedback
>
> Shenwei Wang (4):
>   docs: driver-api: gpio: rpmsg gpio driver over rpmsg bus
>   dt-bindings: remoteproc: imx_rproc: Add "rpmsg" subnode support
>   gpio: rpmsg: add generic rpmsg GPIO driver
>   arm64: dts: imx8ulp: Add rpmsg node under imx_rproc
>
>  .../devicetree/bindings/gpio/gpio-rpmsg.yaml  |  55 ++
>  .../bindings/remoteproc/fsl,imx-rproc.yaml    |  53 ++
>  Documentation/driver-api/gpio/gpio-rpmsg.rst  | 266 ++++++++
>  Documentation/driver-api/gpio/index.rst       |   1 +
>  arch/arm64/boot/dts/freescale/imx8ulp.dtsi    |  25 +
>  drivers/gpio/Kconfig                          |  17 +
>  drivers/gpio/Makefile                         |   1 +
>  drivers/gpio/gpio-rpmsg.c                     | 573 ++++++++++++++++++
>  8 files changed, 991 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/gpio/gpio-rpmsg.yaml
>  create mode 100644 Documentation/driver-api/gpio/gpio-rpmsg.rst
>  create mode 100644 drivers/gpio/gpio-rpmsg.c
>
> --
> 2.43.0
>

Re: [PATCH v13 0/4] Enable Remote GPIO over RPMSG on i.MX Platform

[Andrew Lunn]

On Thu, Apr 23, 2026 at 06:53:12AM -0600, Mathieu Poirier wrote:
> Once again Andrew Lunn was left out.
> 
> On Wed, 22 Apr 2026 at 15:29, Shenwei Wang <shenwei.wang@nxp.com> wrote:
> >
> > Support the remote devices on the remote processor via the RPMSG bus on
> > i.MX platform.
> >
> > Changes in v13:
> >  - drop the support for legacy NXP firmware.
> >  - remove the fixed_up hooks from the rpmsg gpio driver.
> >  - code cleanup.

That looks like a step forward. Now we don't care about legacy NXP
firmware, it makes it easier to make bigger changes, like use the
messages format from gpio-virtio.

	 Andrew

Re: [PATCH v13 0/4] Enable Remote GPIO over RPMSG on i.MX Platform

[Shenwei Wang]

> -----Original Message-----
> From: Andrew Lunn <andrew@lunn.ch>
> Sent: Thursday, April 23, 2026 8:54 AM
> To: Mathieu Poirier <mathieu.poirier@linaro.org>
> Cc: Shenwei Wang <shenwei.wang@nxp.com>; Linus Walleij
> <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>; Jonathan Corbet
> <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof Kozlowski
> <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn Andersson
> <andersson@kernel.org>; Frank Li <frank.li@nxp.com>; Sascha Hauer
> <s.hauer@pengutronix.de>; Shuah Khan <skhan@linuxfoundation.org>; linux-
> gpio@vger.kernel.org; linux-doc@vger.kernel.org; linux-kernel@vger.kernel.org;
> Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
> devicetree@vger.kernel.org; linux-remoteproc@vger.kernel.org;
> imx@lists.linux.dev; linux-arm-kernel@lists.infradead.org; dl-linux-imx <linux-
> imx@nxp.com>
> Subject: [EXT] Re: [PATCH v13 0/4] Enable Remote GPIO over RPMSG on i.MX
> Platform
> 
> 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
> 
> 
> On Thu, Apr 23, 2026 at 06:53:12AM -0600, Mathieu Poirier wrote:
> > Once again Andrew Lunn was left out.
> >
> > On Wed, 22 Apr 2026 at 15:29, Shenwei Wang <shenwei.wang@nxp.com>
> wrote:
> > >
> > > Support the remote devices on the remote processor via the RPMSG bus
> > > on i.MX platform.
> > >
> > > Changes in v13:
> > >  - drop the support for legacy NXP firmware.
> > >  - remove the fixed_up hooks from the rpmsg gpio driver.
> > >  - code cleanup.
> 
> That looks like a step forward. Now we don't care about legacy NXP firmware, it
> makes it easier to make bigger changes, like use the messages format from gpio-
> virtio.
> 

The implementation adopts the gpio‑virtio design, including its commands, parameters, and error codes.

Shenwei

>          Andrew

Re: [PATCH v13 0/4] Enable Remote GPIO over RPMSG on i.MX Platform

[Shenwei Wang]

> -----Original Message-----
> From: Mathieu Poirier <mathieu.poirier@linaro.org>
> Sent: Thursday, April 23, 2026 7:53 AM
> To: Shenwei Wang <shenwei.wang@nxp.com>; Andrew Lunn <andrew@lunn.ch>
> Cc: Linus Walleij <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>;
> Jonathan Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof
> Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn
> Andersson <andersson@kernel.org>; Frank Li <frank.li@nxp.com>; Sascha Hauer
> <s.hauer@pengutronix.de>; Shuah Khan <skhan@linuxfoundation.org>; linux-
> 
> Once again Andrew Lunn was left out.
> 

Seems an issue of get_maintainer.pl, but he is included in the thread for the gpio‑rpmsg driver patch..
Cc: Andrew Lunn <andrew@lunn.ch>

> On Wed, 22 Apr 2026 at 15:29, Shenwei Wang <shenwei.wang@nxp.com>
> wrote:
> >
> > Support the remote devices on the remote processor via the RPMSG bus
> > on i.MX platform.
> >
> > Changes in v13:
> >  - drop the support for legacy NXP firmware.
> >  - remove the fixed_up hooks from the rpmsg gpio driver.
> >  - code cleanup.
> >
> > Changes in v12:
> >  - Fixed the "underline" warning reported by Randy.
> >
> > Changes in v11:
> >  - Expand RPMSG for the first time per Shuah's review comment.
> >
> > Changes in v10:
> >  - Update gpio-rpmsg.rst according to Daniel Baluta's review comments.
> >  - Add a kernel CONFIG for fixed up handlers and only enable it on
> >    i.MX products.
> >  - Fixed bugs reported by kernel test robot.
> >
> > Changes in v9:
> >  - Reuse the gpio-virtio design for command and IRQ type definitions.
> >  - Remove msg_id, version, and vendor fields from the generic protocol.
> >  - Add fixed-up handlers to support legacy firmware.
> >
> > Changes in v8:
> >  - Add "depends on REMOTEPROC" in Kconfig to fix the build error reported
> >    by the kernel test robot.
> >  - Move the .rst patch before the .yaml patch.
> >  - Handle the "ngpios" DT property based on Andrew's feedback.
> >
> > Changes in v7:
> >  - Reworked the driver to use the rpmsg_driver framework instead of
> >    platform_driver, based on feedback from Bjorn and Arnaud.
> >  - Updated gpio-rpmsg.yaml and imx_rproc.yaml according to comments from
> >    Rob and Arnaud.
> >  - Further refinements to gpio-rpmsg.yaml per Arnaud's feedback.
> >
> > Changes in v6:
> >  - make the driver more generic with the actions below:
> >      rename the driver file to gpio-rpmsg.c
> >      remove the imx related info in the function and variable names
> >      rename the imx_rpmsg.h to rpdev_info.h
> >      create a gpio-rpmsg.yaml and refer it in imx_rproc.yaml
> >  - update the gpio-rpmsg.rst according to the feedback from Andrew and
> >    move the source file to driver-api/gpio
> >  - fix the bug reported by Zhongqiu Han
> >  - remove the I2C related info
> >
> > Changes in v5:
> >  - move the gpio-rpmsg.rst from admin-guide to staging directory after
> >    discussion with Randy Dunlap.
> >  - add include files with some code improvements per Bartosz's comments.
> >
> > Changes in v4:
> >  - add a documentation to describe the transport protocol per Andrew's
> >    comments.
> >  - add a new handler to get the gpio direction.
> >
> > Changes in v3:
> >  - fix various format issue and return value check per Peng 's review
> >    comments.
> >  - add the logic to also populate the subnodes which are not in the
> >    device map per Arnaud's request. (in imx_rproc.c)
> >  - update the yaml per Frank's review comments.
> >
> > Changes in v2:
> >  - re-implemented the gpio driver per Linus Walleij's feedback by using
> >    GPIOLIB_IRQCHIP helper library.
> >  - fix various format issue per Mathieu/Peng 's review comments.
> >  - update the yaml doc per Rob's feedback
> >
> > Shenwei Wang (4):
> >   docs: driver-api: gpio: rpmsg gpio driver over rpmsg bus
> >   dt-bindings: remoteproc: imx_rproc: Add "rpmsg" subnode support
> >   gpio: rpmsg: add generic rpmsg GPIO driver
> >   arm64: dts: imx8ulp: Add rpmsg node under imx_rproc
> >
> >  .../devicetree/bindings/gpio/gpio-rpmsg.yaml  |  55 ++
> >  .../bindings/remoteproc/fsl,imx-rproc.yaml    |  53 ++
> >  Documentation/driver-api/gpio/gpio-rpmsg.rst  | 266 ++++++++
> >  Documentation/driver-api/gpio/index.rst       |   1 +
> >  arch/arm64/boot/dts/freescale/imx8ulp.dtsi    |  25 +
> >  drivers/gpio/Kconfig                          |  17 +
> >  drivers/gpio/Makefile                         |   1 +
> >  drivers/gpio/gpio-rpmsg.c                     | 573 ++++++++++++++++++
> >  8 files changed, 991 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/gpio/gpio-rpmsg.yaml
> >  create mode 100644 Documentation/driver-api/gpio/gpio-rpmsg.rst
> >  create mode 100644 drivers/gpio/gpio-rpmsg.c
> >
> > --
> > 2.43.0
> >