+typedef struct pm_message {
+ int event;
+} pm_message_t;
+
+/*
+ * Several driver power state transitions are externally visible, affecting
+ * the state of pending I/O queues and (for drivers that touch hardware)
+ * interrupts, wakeups, DMA, and other hardware state. There may also be
+ * internal transitions to various low power modes, which are transparent
+ * to the rest of the driver stack (such as a driver that's ON gating off
+ * clocks which are not in active use).
+ *
+ * One transition is triggered by resume(), after a suspend() call; the
+ * message is implicit:
+ *
+ * ON Driver starts working again, responding to hardware events
+ * and software requests. The hardware may have gone through
+ * a power-off reset, or it may have maintained state from the
+ * previous suspend() which the driver will rely on while
+ * resuming. On most platforms, there are no restrictions on
+ * availability of resources like clocks during resume().
+ *
+ * Other transitions are triggered by messages sent using suspend(). All
+ * these transitions quiesce the driver, so that I/O queues are inactive.
+ * That commonly entails turning off IRQs and DMA; there may be rules
+ * about how to quiesce that are specific to the bus or the device's type.
+ * (For example, network drivers mark the link state.) Other details may
+ * differ according to the message:
+ *
+ * SUSPEND Quiesce, enter a low power device state appropriate for
+ * the upcoming system state (such as PCI_D3hot), and enable
+ * wakeup events as appropriate.
+ *
+ * FREEZE Quiesce operations so that a consistent image can be saved;
+ * but do NOT otherwise enter a low power device state, and do
+ * NOT emit system wakeup events.
+ *
+ * PRETHAW Quiesce as if for FREEZE; additionally, prepare for restoring
+ * the system from a snapshot taken after an earlier FREEZE.
+ * Some drivers will need to reset their hardware state instead
+ * of preserving it, to ensure that it's never mistaken for the
+ * state which that earlier snapshot had set up.
+ *
+ * A minimally power-aware driver treats all messages as SUSPEND, fully
+ * reinitializes its device during resume() -- whether or not it was reset
+ * during the suspend/resume cycle -- and can't issue wakeup events.
+ *
+ * More power-aware drivers may also use low power states at runtime as
+ * well as during system sleep states like PM_SUSPEND_STANDBY. They may
+ * be able to use wakeup events to exit from runtime low-power states,
+ * or from system low-power states such as standby or suspend-to-RAM.
+ */
+
+#define PM_EVENT_ON 0
+#define PM_EVENT_FREEZE 1
+#define PM_EVENT_SUSPEND 2
+#define PM_EVENT_PRETHAW 3
+
+#define PMSG_FREEZE ((struct pm_message){ .event = PM_EVENT_FREEZE, })
+#define PMSG_PRETHAW ((struct pm_message){ .event = PM_EVENT_PRETHAW, })
+#define PMSG_SUSPEND ((struct pm_message){ .event = PM_EVENT_SUSPEND, })
+#define PMSG_ON ((struct pm_message){ .event = PM_EVENT_ON, })
+