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: <20250918131230.GD9196@nxa18884-linux.ap.freescale.net>
Date: Thu, 18 Sep 2025 21:12:30 +0800
From: Peng Fan <peng.fan@....nxp.com>
To: Dhruva Gole <d-gole@...com>
Cc: Peng Fan <peng.fan@....com>, 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()

Hi Dhruva,

On Thu, Sep 18, 2025 at 03:29:50PM +0530, Dhruva Gole wrote:
>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.

I should join today's SCMI meeting, but something else caught me (:

Thanks for looking into this. 

In genpd_suspend_finish, genpd_sync_power_off will be called if
"(device_awake_path(dev) && genpd_is_active_wakeup(genpd))" is false.
So if the device is enabled wakeup, the genpd will not be turned off because
the check return true.

But to i.MX, if the device is configured as wakeup source, we still need to
power off the power domain, because the device has out-of-band wakeup logic.

This patch is to make sure the power domain could be powered off in
suspend flow and powered up in resume flow.

Thanks,
Peng

>
>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