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

Andrew Lunn andrew at lunn.ch
Thu Feb 19 07:25:04 PST 2026


On Thu, Feb 19, 2026 at 02:17:26PM +0000, Shenwei Wang wrote:
> 
> 
> > -----Original Message-----
> > From: Andrew Lunn <andrew at lunn.ch>
> > Sent: Thursday, February 19, 2026 7:27 AM
> > To: Arnaud POULIQUEN <arnaud.pouliquen at foss.st.com>
> > Cc: Shenwei Wang <shenwei.wang at nxp.com>; Linus Walleij
> > <linusw at kernel.org>; Bartosz Golaszewski <brgl at kernel.org>; Jonathan Corbet
> > <corbet at lwn.net>; Rob Herring <robh at kernel.org>; Krzysztof Kozlowski
> > <krzk+dt at kernel.org>; Conor Dooley <conor+dt at kernel.org>; Bjorn Andersson
> > <andersson at kernel.org>; Mathieu Poirier <mathieu.poirier at linaro.org>; Frank Li
> > <frank.li at nxp.com>; Sascha Hauer <s.hauer at pengutronix.de>; Shuah Khan
> > <skhan at linuxfoundation.org>; linux-gpio at vger.kernel.org; linux-
> > doc at vger.kernel.org; linux-kernel at vger.kernel.org; Pengutronix Kernel Team
> > <kernel at pengutronix.de>; Fabio Estevam <festevam at gmail.com>; Peng Fan
> > <peng.fan at nxp.com>; devicetree at vger.kernel.org; linux-
> > remoteproc at vger.kernel.org; imx at lists.linux.dev; linux-arm-
> > kernel at lists.infradead.org; dl-linux-imx <linux-imx at nxp.com>; Bartosz
> > Golaszewski <brgl at bgdev.pl>
> > Subject: [EXT] Re: [PATCH v8 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
> > 
> > > > +   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



More information about the linux-arm-kernel mailing list