> -----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.
Thanks,
Shenwei
> Andrew
