On 11/17/2013 03:15 PM, Rafael J. Wysocki wrote:
On Saturday, November 09, 2013 06:36:17 PM al.stone@xxxxxxxxxx wrote:
From: Al Stone <ahs3@xxxxxxxxxx>
Since some of the FADT fields reserved are not to be used by the OSPM,
"are not to be used by the OSPM in the HW reduced mode" would be clearer.
Good suggestion. I'll add it in.
do not map in the memory areas that the FADT fields reference.
Signed-off-by: Al Stone <al.stone@xxxxxxxxxx>
---
drivers/acpi/osl.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 075545e..2750cb5 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -160,6 +160,9 @@ static u32 acpi_osi_handler(acpi_string interface, u32 supported)
return supported;
}
+#ifdef CONFIG_ACPI_REDUCED_HARDWARE
+static int __init acpi_reserve_resources(void) { return 0; }
+#else
static void __init acpi_request_region (struct acpi_generic_address *gas,
unsigned int length, char *desc)
{
@@ -209,6 +212,7 @@ static int __init acpi_reserve_resources(void)
return 0;
}
+#endif
device_initcall(acpi_reserve_resources);
Do we need the device_initcall() above at all if CONFIG_ACPI_REDUCED_HARDWARE
is unset?
Sigh -- off-by-one error on the #endif. No, it's not really
needed; I'll fix that.
void acpi_os_printf(const char *fmt, ...)
@@ -1782,6 +1786,9 @@ static int __init acpi_no_auto_ssdt_setup(char *s)
__setup("acpi_no_auto_ssdt", acpi_no_auto_ssdt_setup);
+#ifdef CONFIG_ACPI_REDUCED_HARDWARE
+acpi_status __init acpi_os_initialize(void) { return AE_OK; }
+#else
acpi_status __init acpi_os_initialize(void)
{
acpi_os_map_generic_address(&acpi_gbl_FADT.xpm1a_event_block);
@@ -1791,6 +1798,7 @@ acpi_status __init acpi_os_initialize(void)
return AE_OK;
}
+#endif
acpi_status __init acpi_os_initialize1(void)
{
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Linaro Enterprise Group
al.stone@xxxxxxxxxx
-----------------------------------
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
