Thread (69 messages) 69 messages, 8 authors, 2026-02-27

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

From: Shenwei Wang <shenwei.wang@nxp.com>
Date: 2026-02-19 16:42:30
Also in: imx, linux-devicetree, linux-doc, linux-gpio, linux-remoteproc, lkml

-----Original Message-----
From: Andrew Lunn <andrew@lunn.ch>
Sent: Thursday, February 19, 2026 9:25 AM
To: Shenwei Wang <shenwei.wang@nxp.com>
Cc: Arnaud POULIQUEN <arnaud.pouliquen@foss.st.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 v8 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
On Thu, Feb 19, 2026 at 02:17:26PM +0000, Shenwei Wang wrote:
quoted
quoted
-----Original Message-----
From: Andrew Lunn <andrew@lunn.ch>
Sent: Thursday, February 19, 2026 7:27 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 v8 3/4] gpio: rpmsg: add generic rpmsg
GPIO driver
quoted
quoted
+   if (sync) {
+           err = wait_for_completion_timeout(&info->cmd_complete,
+                                             msecs_to_jiffies(RPMSG_TIMEOUT));
+           if (err == 0) {
+                   dev_err(&info->rpdev->dev, "rpmsg_send timeout!\n");
+                   return -ETIMEDOUT;
strange condition you return an error if err == 0, for redability use 'ret'
variable or simply:

              if(!wait_for_completion_timeout(&info->cmd_complete,
                                msecs_to_jiffies(RPMSG_TIMEOUT)) {
                      dev_err(&info->rpdev->dev, "rpmsg_send timeout!\n");
                      return -ETIMEDOUT;
              }
This will be from a comment i made. It appears that
do_wait_for_common() can return -ERESTARTSYS. I assume that should
be returned to user space?
It looks like there might be a bit of confusion around what
wait_for_completion_timeout() actually returns. That function never
returns -ERESTARTSYS. Instead, its behavior is pretty
simple:

- 0 means the wait timed out
- A positive value means the completion happened (the value is just
the remaining jiffies)

So the driver returns the timeout error, and the upper application can
decide how it wants to handle that situation, for example restart or ignore.
wait_for_completion_timeout():
        return wait_for_common(x, timeout, TASK_UNINTERRUPTIBLE);

wait_for_common():
        return __wait_for_common(x, io_schedule_timeout, timeout, state);

__wait_for_common():
        timeout = do_wait_for_common(x, action, timeout, state);
        ...
        return timeout;

do_wait_for_common():

                do {
                        if (signal_pending_state(state, current)) {
                                timeout = -ERESTARTSYS;
Once wait_for_common() is called with state = TASK_UNINTERRUPTIBLE, signal_pending_state() will 
always return false. As a result, -ERESTARTSYS is not a possible return value in this scenario.

Thanks,
Shenwei 
                                break;
                        }
...
                } while (!x->done && timeout); ...
                if (!x->done)
                        return timeout;
...
        return timeout ?: 1;
        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