Patchsets related to hibernation resume:
- enhancement to make the use of an existing resume file more general
- enhance name_to_dev_t to ignore trailing newlines coming from userspace.
Both patches are based on the 3.12-rc3 tag. This was tested on a
Pandaboard with partial hibernation support, and compiled for x86.
[PATCH 1/2] init/do_mounts.c: ignore final \n in name_to_dev_t
init/do_mounts.c | 23 ++++++++++++++++++-----
1 file changed, 18 insertions(+), 5 deletions(-)
Changes name_to_dev_t to handle a trailing newline in the
input buffer, which will allow name_to_dev_t to be used
directly with user buffers without requiring a copy.
Also adds a const to the name parameter which reflects
how name_to_dev_t is treating the input buffer currently.
This also allows direct use of user buffers
(from resume_store for example).
[PATCH 2/2] PM / Hibernate: use name_to_dev_t to parse resume
kernel/power/hibernate.c | 15 ++++-----------
1 file changed, 4 insertions(+), 11 deletions(-)
Use name_to_dev_t to parse the /sys/power/resume file making the
syntax more flexible. It supports the previous use syntax
and additionally can support other formats such as
/dev/devicenode and UUID= formats.
By changing /sys/debug/resume to accept the same syntax as
the resume=device parameter, we can parse the resume=device
in the initrd init script and use the resume device directly
from the kernel command line.
Changes in v3:
--------------
* Dropped documentation patch as it went in through trivial
* Added patch for name_to_dev_t to support directly parsing userspace
buffer
Changes in v2:
--------------
* Added check for null return of kstrndup in hibernate.c
Thanks,
Sebastian
From: Mark Brown <broonie(a)linaro.org>
There is currently no facility in ACPI to express the hookup of voltage
regulators, the expectation is that the regulators that exist in the
system will be handled transparently by firmware if they need software
control at all. This means that if for some reason the regulator API is
enabled on such a system it should assume that any supplies that devices
need are provided by the system at all relevant times without any software
intervention.
Tell the regulator core to make this assumption by calling
regulator_has_full_constraints(). Do this as soon as we know we are using
ACPI so that the information is available to the regulator core as early
as possible. This will cause the regulator core to pretend that there is
an always on regulator supplying any supply that is requested but that has
not otherwise been mapped which is the behaviour expected on a system with
ACPI.
Should the ability to specify regulators be added in future revisions of
ACPI then once we have support for ACPI mappings in the kernel the same
assumptions will apply. It is also likely that systems will default to a
mode of operation which does not require any interpretation of these
mappings in order to be compatible with existing operating system releases
so it should remain safe to make these assumptions even if the mappings
exist but are not supported by the kernel.
Signed-off-by: Mark Brown <broonie(a)linaro.org>
---
drivers/acpi/bus.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 384da5ab5955..fcb59c21c68d 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -33,6 +33,7 @@
#include <linux/proc_fs.h>
#include <linux/acpi.h>
#include <linux/slab.h>
+#include <linux/regulator/machine.h>
#ifdef CONFIG_X86
#include <asm/mpspec.h>
#endif
@@ -509,6 +510,14 @@ void __init acpi_early_init(void)
goto error0;
}
+ /*
+ * If the system is using ACPI then we can be reasonably
+ * confident that any regulators are managed by the firmware
+ * so tell the regulator core it has everything it needs to
+ * know.
+ */
+ regulator_has_full_constraints();
+
return;
error0:
--
1.8.5.3
