Thread (22 messages) 22 messages, 5 authors, 2026-03-23

Re: [PATCH v12 3/5] gpio: rpmsg: add generic rpmsg GPIO driver

From: Shenwei Wang <shenwei.wang@nxp.com>
Date: 2026-03-17 15:59:57
Also in: imx, linux-devicetree, linux-doc, linux-gpio, linux-remoteproc, lkml

-----Original Message-----
From: Andrew Lunn <andrew@lunn.ch>
Sent: Tuesday, March 17, 2026 9:22 AM
To: Arnaud POULIQUEN <arnaud.pouliquen@foss.st.com>
Cc: Shenwei Wang <shenwei.wang@nxp.com>; Linus Walleij
[off-list ref]; Bartosz Golaszewski [off-list ref]; Jonathan Corbet
[off-list ref]; Rob Herring [off-list ref]; Krzysztof Kozlowski
[off-list ref]; Conor Dooley [off-list ref]; Bjorn Andersson
[off-list ref]; Mathieu Poirier [off-list ref]; Frank Li
[off-list ref]; Sascha Hauer [off-list ref]; Shuah Khan
[off-list ref]; linux-gpio@vger.kernel.org; linux-
doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix Kernel Team
[off-list ref]; Fabio Estevam [off-list ref]; Peng Fan
[off-list ref]; devicetree@vger.kernel.org; linux-
remoteproc@vger.kernel.org; imx@lists.linux.dev; linux-arm-
kernel@lists.infradead.org; dl-linux-imx [off-list ref]; Bartosz
Golaszewski [off-list ref]
Subject: [EXT] Re: [PATCH v12 3/5] gpio: rpmsg: add generic rpmsg GPIO driver
quoted
quoted
+static int rpmsg_gpio_send_message(struct rpmsg_gpio_port *port,
+                              struct rpmsg_gpio_packet *msg,
+                              bool sync) {
+   struct rpmsg_gpio_info *info = &port->info;
+   struct rpdev_drvdata *drvdata;
+   int ret;
+
+   drvdata = dev_get_drvdata(&info->rpdev->dev);
+   reinit_completion(&info->cmd_complete);
+
+   if (drvdata->protocol_fixed_up)
+           ret = drvdata->protocol_fixed_up->send_fixed_up(info,
+ msg);
Seems not part of a generic implementation
Agreed. Lets have a clean generic implementation first, and then patches on top
for legacy stuff.
Adding fixed_up hooks doesn't make the implementation non-generic-this pattern is 
widely used in Linux drivers.

Shenwei
quoted
quoted
+   ret = of_property_read_u32(np, "ngpios", &port->ngpios);
The number of GPIOs should be obtained from the remote side, as done
in virtio_gpio. In virtio_gpio, this is retrieved via a get_config operation.
Here, you could implement a specific RPMsg to retrieve the remote topology.
The DT property ngpios is pretty standard, so i think it makes a lot of sense to
have. But i also agree that asking the other side makes sense. What is being
implemented here with rpmsg is not that different to greybus, and the greybus
GPIO driver also ask the other side how many GPIO lines it has. So yes, it should
be part of the protocol, but maybe optional?

          Andrew
  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help