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

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

From: Andrew Lunn <andrew@lunn.ch>
Date: 2026-02-19 15:25:15
Also in: imx, linux-devicetree, linux-doc, linux-gpio, linux-remoteproc, lkml

On Thu, Feb 19, 2026 at 02:17:26PM +0000, Shenwei Wang wrote:
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;
				break;
			}
...		
		} while (!x->done && timeout);
...
		if (!x->done)
			return timeout;
...
	return timeout ?: 1;

This last line is interesting, and i had to go look at the
documentation:

https://gcc.gnu.org/onlinedocs/gcc/Conditionals.html

So this is equivalent to

        return timeout ? timeout : 1;

Hence, it does appear wait_for_completion_timeout() can return
-ERESTARTSYS

There is however a comment in include/linux/errno.h

/*
 * These should never be seen by user programs.  To return one of ERESTART*
 * codes, signal_pending() MUST be set.  Note that ptrace can observe these
 * at syscall exit tracing, but they will never be left for the debugged user
 * process to see.
 */
#define ERESTARTSYS	512

So we do seem to be talking about a corner case, allowing gdb(1) to
know about it, but not user space.

	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