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

Shenwei Wang shenwei.wang at nxp.com
Thu Feb 19 08:42:25 PST 2026



> -----Original Message-----
> From: Andrew Lunn <andrew at lunn.ch>
> Sent: Thursday, February 19, 2026 9:25 AM
> To: Shenwei Wang <shenwei.wang at nxp.com>
> Cc: Arnaud POULIQUEN <arnaud.pouliquen at foss.st.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
> 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;

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



More information about the linux-arm-kernel mailing list