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] [day] [month] [year] [list]

Message-ID: <01edc2c2-fd1e-479d-8f65-a07b0ed634e1@lunn.ch>
Date: Mon, 10 Nov 2025 18:58:23 +0100
From: Andrew Lunn <andrew@...n.ch>
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" <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

On Mon, Nov 10, 2025 at 04:30:29PM +0000, Shenwei Wang wrote:
> 
> 
> > -----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.

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