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: <0980eb35-b3fd-4383-af86-433769a4fd97@lunn.ch>
Date: Sat, 8 Nov 2025 18:45:46 +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

> > > The power state of the remote GPIO controller is entirely managed by the
> > remote firmware.
> > > The remote firmware operates as an independent system from Linux, with
> > > its own power states and policies for transitioning between modes. The
> > > wakeup field is solely intended to inform the remote firmware whether the
> > GPIO line should be used as a wakeup source for the Linux system.
> > 
> > O.K. How does the firmware use this information? How should it change its
> > behaviour?
> > 
> 
> The remote system should always aim to stay in a power-efficient state by shutting down 
> or clock-gating any blocks that aren't in use. In this wakeup scenario, if no GPIO lines are 
> requested or marked as wakeup sources for Linux, the remote firmware should put the 
> GPIO controller into a low-power state.

There are no messages defined to tell the GPIO controller Linux is
suspended.

Since the firmware has no idea Linux is asleep, the firmware is
performing all the usual processing, driving output pins, monitoring
input pins, delivering interrupt notifications. If no pins are marked
as wakeup, it can then enter some sort of low-power state, which
allows it to do all this work, plus save power? How?

I've also been thinking about what a wake up source actually
means. I've been looking at this from one use case i know, an Ethernet
PHY performing Wake on LAN? What normally happens is that Linux
suspends, but leaves the main SoC interrupt controller enabled, and
parts of the GPIO controller. The GPIO controller has a hard wired
connection to the interrupt controller. When the PHY indicated WoL by
driving its output pin low, triggering an interrupt, the GPIO triggers
the main interrupt controller, which wakes the CPU.

How does this work here, in a message passing system? Linux is
asleep. While asleep, does it still process all remote proc messages?
How? Does it wake up for each message and go back to sleep once it
finds it is a non wake notification? Since the firmware does not know
Linux is asleep, it will still be sending notifications for non-wake
interrupts. How does Linux actually know to wake up? Do you require
that the low level remote proc mechanism is also wake capable? So in
effect, Linux needs to go up the device chain and enable wake source
not only in the GPIO layer but also the remote proc layer? And
whatever mechanism that is based on, until you get to an interrupt
which can actually wake the system?

> Okay. To fully simulate a level-triggered interrupt, a notification reply message is required.

I would not word it like that. All you currently have is edge. To
simulate level triggered interrupts you need a notification reply
message.

> Remote firmware sequence:
> Receive the level-triggered GPIO interrupt.
> Mask the interrupt for the corresponding line.
> Send a notification message to Linux.
> Wait for the notification reply, then unmask the interrupt for the line.
> 
> Linux sequence:
> Receive the notification message.
> Invoke the interrupt handler for the line.
> Send a notification reply to the remote firmware to indicate End of Interrupt (EOI).

That sounds more reasonable.

	Andrew