On Mon, Nov 10, 2025 at 04:30:29PM +0000, Shenwei Wang wrote:
>
>
> > -----Original Message-----
> > From: Andrew Lunn <[email protected]>
> > Sent: Monday, November 10, 2025 9:59 AM
> > To: Shenwei Wang <[email protected]>
> > Cc: Bjorn Andersson <[email protected]>; Mathieu Poirier
> > <[email protected]>; Rob Herring <[email protected]>; Krzysztof
> > Kozlowski <[email protected]>; Conor Dooley <[email protected]>; Shawn
> > Guo <[email protected]>; Sascha Hauer <[email protected]>;
> > Jonathan Corbet <[email protected]>; Linus Walleij <[email protected]>;
> > Bartosz Golaszewski <[email protected]>; Pengutronix Kernel Team
> > <[email protected]>; Fabio Estevam <[email protected]>; Peng Fan
> > <[email protected]>; [email protected];
> > [email protected]; [email protected]; linux-arm-
> > [email protected]; [email protected]; linux-
> > [email protected]; dl-linux-imx <[email protected]>
> > 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
