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 driverquoted
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