diff options
author | Geert Uytterhoeven <geert+renesas@linux-m68k.org> | 2014-03-18 00:26:10 +0400 |
---|---|---|
committer | Rafael J. Wysocki <rafael.j.wysocki@intel.com> | 2014-03-20 16:03:22 +0400 |
commit | 33fe0ad946bbb0a2f04f551fce68a74d8821f32e (patch) | |
tree | a35e78078702c6ad252b05ae738c8e24c03b8e56 /include/linux/pm.h | |
parent | af02b5fdb1fb3c5d5f8d71f7f84e4fb243e1ae31 (diff) | |
download | linux-33fe0ad946bbb0a2f04f551fce68a74d8821f32e.tar.xz |
PM / sleep: Correct whitespace errors in <linux/pm.h>
rjw> Why exactly are they errors?
Geert> checkpatch.pl says: "WARNING: please, no space before tabs",
Vim (with "let c_space_errors=1") shows them in red.
Signed-off-by: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Diffstat (limited to 'include/linux/pm.h')
-rw-r--r-- | include/linux/pm.h | 32 |
1 files changed, 16 insertions, 16 deletions
diff --git a/include/linux/pm.h b/include/linux/pm.h index 6fffbcd7bc37..f902ad83986e 100644 --- a/include/linux/pm.h +++ b/include/linux/pm.h @@ -379,7 +379,7 @@ const struct dev_pm_ops name = { \ * * ON No transition. * - * FREEZE System is going to hibernate, call ->prepare() and ->freeze() + * FREEZE System is going to hibernate, call ->prepare() and ->freeze() * for all devices. * * SUSPEND System is going to suspend, call ->prepare() and ->suspend() @@ -423,7 +423,7 @@ const struct dev_pm_ops name = { \ #define PM_EVENT_INVALID (-1) #define PM_EVENT_ON 0x0000 -#define PM_EVENT_FREEZE 0x0001 +#define PM_EVENT_FREEZE 0x0001 #define PM_EVENT_SUSPEND 0x0002 #define PM_EVENT_HIBERNATE 0x0004 #define PM_EVENT_QUIESCE 0x0008 @@ -614,11 +614,11 @@ struct dev_pm_domain { * 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(). + * 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. @@ -628,21 +628,21 @@ struct dev_pm_domain { * 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. + * the upcoming system state (such as PCI_D3hot), and enable + * wakeup events as appropriate. * * HIBERNATE Enter a low power device state appropriate for the hibernation - * state (eg. ACPI S4) and enable wakeup events as appropriate. + * state (eg. ACPI S4) 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. + * 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. + * 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 |