Re: [PATCH v5 3/5] docs: staging: gpio-rpmsg: gpio over rpmsg bus

Andrew Lunn
2025-11-10T17:58:31Z

On Mon, Nov 10, 2025 at 04:30:29PM +0000, Shenwei Wang wrote:
>
>
> > -----Original Message-----
> > From: Andrew Lunn <andrew@lunn.ch>
> > Sent: Monday, November 10, 2025 9:59 AM
> > To: Shenwei Wang <shenwei.wang@nxp.com>
> > Cc: Bjorn Andersson <andersson@kernel.org>; Mathieu Poirier
> > <mathieu.poirier@linaro.org>; Rob Herring <robh@kernel.org>; Krzysztof
> > Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Shawn
> > Guo <shawnguo@kernel.org>; Sascha Hauer <s.hauer@pengutronix.de>;
> > Jonathan Corbet <corbet@lwn.net>; Linus Walleij <linus.walleij@linaro.org>;
> > Bartosz Golaszewski <brgl@bgdev.pl>; Pengutronix Kernel Team
> > <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; Peng Fan
> > <peng.fan@nxp.com>; linux-remoteproc@vger.kernel.org;
> > devicetree@vger.kernel.org; imx@lists.linux.dev; linux-arm-
> > kernel@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
> > doc@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>
> > Subject: [EXT] Re: [PATCH v5 3/5] docs: staging: gpio-rpmsg: gpio over rpmsg bus
> > > The remote firmware does not need to know whether Linux is asleep. The
> > > GPIO is not used to wake Linux directly; instead, it serves as a
> > > wake-up source for the remote firmware if configured accordingly. Once
> > > the remote firmware is awake, it sends a notification message to Linux. This
> > notification is the actual event that wakes Linux.
> > >
> > > This works because there is always a physical interface connecting Linux and
> > the remote firmware.
> > > On i.MX platforms, this interface is the MU block. When the remoteproc
> > > driver is running, the MU block is automatically configured as a
> > > wake-up source for Linux by default. As a result, the notification message can
> > wake the Linux system if it is asleep.
> >
> > You need to add a lot more documentation to the specification to make this
> > clear. As you said, the firmware and Linux have different sleep/wake life cycles.
> > How does the firmware know it is safe to go to sleep, if it has no idea Linux is
> > running or suspended?
> >
>
> The remoteproc driver is responsible for managing the remote firmware. The GPIO driver
> operates independently of this process and functions transparently on top of it.
> So the GPIO driver does not require to know the firmware's running states.

Great. Just document this. Document what are the
expectations/assumptions about the channel. The specification needs to
be clear enough that somebody can implement it. At the moment, i doubt
anybody would get this correct from the specification alone.

Andrew