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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <PAXPR04MB9185F5CC1FEE1557B6AD320889CEA@PAXPR04MB9185.eurprd04.prod.outlook.com>
Date: Mon, 10 Nov 2025 16:30:29 +0000
From: Shenwei Wang <shenwei.wang@....com>
To: Andrew Lunn <andrew@...n.ch>
CC: Bjorn Andersson <andersson@...nel.org>, Mathieu Poirier
	<mathieu.poirier@...aro.org>, Rob Herring <robh@...nel.org>, Krzysztof
 Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, Shawn Guo
	<shawnguo@...nel.org>, Sascha Hauer <s.hauer@...gutronix.de>, Jonathan Corbet
	<corbet@....net>, Linus Walleij <linus.walleij@...aro.org>, Bartosz
 Golaszewski <brgl@...ev.pl>, Pengutronix Kernel Team <kernel@...gutronix.de>,
	Fabio Estevam <festevam@...il.com>, Peng Fan <peng.fan@....com>,
	"linux-remoteproc@...r.kernel.org" <linux-remoteproc@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"imx@...ts.linux.dev" <imx@...ts.linux.dev>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "linux-doc@...r.kernel.org"
	<linux-doc@...r.kernel.org>, dl-linux-imx <linux-imx@....com>
Subject: Re: [PATCH v5 3/5] docs: staging: gpio-rpmsg: gpio over rpmsg bus



> -----Original Message-----
> From: Andrew Lunn <andrew@...n.ch>
> Sent: Monday, November 10, 2025 9:59 AM
> To: Shenwei Wang <shenwei.wang@....com>
> Cc: Bjorn Andersson <andersson@...nel.org>; Mathieu Poirier
> <mathieu.poirier@...aro.org>; Rob Herring <robh@...nel.org>; Krzysztof
> Kozlowski <krzk+dt@...nel.org>; Conor Dooley <conor+dt@...nel.org>; Shawn
> Guo <shawnguo@...nel.org>; Sascha Hauer <s.hauer@...gutronix.de>;
> Jonathan Corbet <corbet@....net>; Linus Walleij <linus.walleij@...aro.org>;
> Bartosz Golaszewski <brgl@...ev.pl>; Pengutronix Kernel Team
> <kernel@...gutronix.de>; Fabio Estevam <festevam@...il.com>; Peng Fan
> <peng.fan@....com>; linux-remoteproc@...r.kernel.org;
> devicetree@...r.kernel.org; imx@...ts.linux.dev; linux-arm-
> kernel@...ts.infradead.org; linux-kernel@...r.kernel.org; linux-
> doc@...r.kernel.org; dl-linux-imx <linux-imx@....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.

Thanks,
Shenwei

>         Andrew