linux-kernel - PM: knowing the system state in the device callback

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

Date:	Mon, 16 Mar 2015 20:17:42 +0100
From:	Alexandre Belloni <alexandre.belloni@...e-electrons.com>
To:	"Rafael J. Wysocki" <rjw@...ysocki.net>
Cc:	Pavel Machek <pavel@....cz>,
	Boris Brezillon <boris.brezillon@...e-electrons.com>,
	Nicolas Ferre <nicolas.ferre@...el.com>,
	linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org
Subject: PM: knowing the system state in the device callback

Hi,

I'm trying to get rid of at91_suspend_entering_slow_clock() which is
exposing the platform suspend_state_t to the devices. From what I
understand, whenever suspend_state_t is PM_SUSPEND_MEM or
PM_SUSPEND_STANDBY, the pm_message_t passed to the device driver is
always PM_EVENT_SUSPEND.

The requirement is to know whether we are going to cut the master clock
and in that case, avoid calling enable_irq_wake() because we will not be
able to wakeup from the device.

Is there a better way to do that? Or should I implement a similar
function in the pm core (which I guess would already be there if
really needed)?

Regards,

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/