linux-kernel - Re: [PATCH v3 1/4] pmdomain: core: Introduce device_set/get_out_band

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: <20250918095950.h7wmz2qj5e6khtwr@lcpd911>
Date: Thu, 18 Sep 2025 15:29:50 +0530
From: Dhruva Gole <d-gole@...com>
To: Peng Fan <peng.fan@....com>
CC: Ulf Hansson <ulf.hansson@...aro.org>,
        "Rafael J. Wysocki"
	<rafael@...nel.org>, Len Brown <lenb@...nel.org>,
        Pavel Machek
	<pavel@...nel.org>, Peter Chen <peter.chen@...nel.org>,
        Greg Kroah-Hartman
	<gregkh@...uxfoundation.org>,
        Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer
	<s.hauer@...gutronix.de>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Fabio Estevam <festevam@...il.com>,
        Thinh Nguyen <Thinh.Nguyen@...opsys.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Xu Yang <xu.yang_2@....com>, <linux-pm@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <linux-usb@...r.kernel.org>,
        <imx@...ts.linux.dev>, <arm-scmi@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v3 1/4] pmdomain: core: Introduce
 device_set/get_out_band_wakeup()

On Sep 02, 2025 at 11:33:00 +0800, Peng Fan wrote:
> For some cases, a device could still wakeup the system even if its power
> domain is in off state, because the device's wakeup hardware logic is
> in an always-on domain.
> 
> To support this case, introduce device_set/get_out_band_wakeup() to
> allow device drivers to control the behaviour in genpd for a device
> that is attached to it.
> 

Thinking more into it, to me it seems like if the intent here is to only
allow the device drivers to figure out whether they should be or not be
executing the suspend/resume_noirqs then that can still be checked by
wisely using the device set_wakeup APIs in the driver itself.

Not sure why this patch should be necessary for a
driver to execute the suspend_noirq or not. That decision can very well
be taken inside the driver's suspend resume_noirq hooks based on wakeup
capability and wake_enabled statuses.

Just a pseudo code:
```
driver_suspend_noirq () {
	if (device_may_wakeup()) {
		// do the sequence where the power domain might get turned off
		// but like you say device can do some out band wakeup
		return XXX;
	}
	// regular suspend sequence here... maybe inband wakeup config / clk
	// disable etc...
}
 ```

And something similar in resume_noirq?

Just need to make sure that the probe func does the
device_set_wakeup_enable or capable stuff correctly as per your H/w and
wakeup requirements...


-- 
Best regards,
Dhruva Gole
Texas Instruments Incorporated