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

[Andrew Lunn]

On Mon, Nov 10, 2025 at 04:30:29PM +0000, Shenwei Wang wrote:
> 
> 
> > -----Original Message-----
> > From: Andrew Lunn <andrew at lunn.ch>
> > Sent: Monday, November 10, 2025 9:59 AM
> > To: Shenwei Wang <shenwei.wang at nxp.com>
> > Cc: Bjorn Andersson <andersson at kernel.org>; Mathieu Poirier
> > <mathieu.poirier at linaro.org>; Rob Herring <robh at kernel.org>; Krzysztof
> > Kozlowski <krzk+dt at kernel.org>; Conor Dooley <conor+dt at kernel.org>; Shawn
> > Guo <shawnguo at kernel.org>; Sascha Hauer <s.hauer at pengutronix.de>;
> > Jonathan Corbet <corbet at lwn.net>; Linus Walleij <linus.walleij at linaro.org>;
> > Bartosz Golaszewski <brgl at bgdev.pl>; Pengutronix Kernel Team
> > <kernel at pengutronix.de>; Fabio Estevam <festevam at gmail.com>; Peng Fan
> > <peng.fan at nxp.com>; linux-remoteproc at vger.kernel.org;
> > devicetree at vger.kernel.org; imx at lists.linux.dev; linux-arm-
> > kernel at lists.infradead.org; linux-kernel at vger.kernel.org; linux-
> > doc at vger.kernel.org; dl-linux-imx <linux-imx at 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