From 038d7b593563818c5e9bc61e05c7f5ce1ce8e3ef Mon Sep 17 00:00:00 2001 From: Hanjun Guo Date: Fri, 17 Jan 2014 12:37:02 +0800 Subject: ACPI / processor: Return specific error value when mapping lapic id Usually, 0 is returned for success in int-returning functions and negative value are returned on failure, but in processor_core.c, some function return 1 for success and 0 for failure which causes confusion to happen sometimes, so modify the functions in question to follow the common convention.. Signed-off-by: Hanjun Guo [rjw: Changelog] Signed-off-by: Rafael J. Wysocki --- drivers/acpi/processor_core.c | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) (limited to 'drivers/acpi') diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c index b3171f3..24c87ef 100644 --- a/drivers/acpi/processor_core.c +++ b/drivers/acpi/processor_core.c @@ -45,13 +45,13 @@ static int map_lapic_id(struct acpi_subtable_header *entry, (struct acpi_madt_local_apic *)entry; if (!(lapic->lapic_flags & ACPI_MADT_ENABLED)) - return 0; + return -ENODEV; if (lapic->processor_id != acpi_id) - return 0; + return -EINVAL; *apic_id = lapic->id; - return 1; + return 0; } static int map_x2apic_id(struct acpi_subtable_header *entry, @@ -61,14 +61,14 @@ static int map_x2apic_id(struct acpi_subtable_header *entry, (struct acpi_madt_local_x2apic *)entry; if (!(apic->lapic_flags & ACPI_MADT_ENABLED)) - return 0; + return -ENODEV; if (device_declaration && (apic->uid == acpi_id)) { *apic_id = apic->local_apic_id; - return 1; + return 0; } - return 0; + return -EINVAL; } static int map_lsapic_id(struct acpi_subtable_header *entry, @@ -78,16 +78,16 @@ static int map_lsapic_id(struct acpi_subtable_header *entry, (struct acpi_madt_local_sapic *)entry; if (!(lsapic->lapic_flags & ACPI_MADT_ENABLED)) - return 0; + return -ENODEV; if (device_declaration) { if ((entry->length < 16) || (lsapic->uid != acpi_id)) - return 0; + return -EINVAL; } else if (lsapic->processor_id != acpi_id) - return 0; + return -EINVAL; *apic_id = (lsapic->id << 8) | lsapic->eid; - return 1; + return 0; } static int map_madt_entry(int type, u32 acpi_id) @@ -117,13 +117,13 @@ static int map_madt_entry(int type, u32 acpi_id) struct acpi_subtable_header *header = (struct acpi_subtable_header *)entry; if (header->type == ACPI_MADT_TYPE_LOCAL_APIC) { - if (map_lapic_id(header, acpi_id, &apic_id)) + if (!map_lapic_id(header, acpi_id, &apic_id)) break; } else if (header->type == ACPI_MADT_TYPE_LOCAL_X2APIC) { - if (map_x2apic_id(header, type, acpi_id, &apic_id)) + if (!map_x2apic_id(header, type, acpi_id, &apic_id)) break; } else if (header->type == ACPI_MADT_TYPE_LOCAL_SAPIC) { - if (map_lsapic_id(header, type, acpi_id, &apic_id)) + if (!map_lsapic_id(header, type, acpi_id, &apic_id)) break; } entry += header->length; -- cgit v1.1 From f778d1218f10504a87353c696faf116481fa27a6 Mon Sep 17 00:00:00 2001 From: Jiang Liu Date: Mon, 27 Jan 2014 14:34:58 +0800 Subject: ACPI / scan: reduce log level of "ACPI: \_PR_.CPU4: failed to get CPU APIC ID" MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Commit b981513f806d (ACPI / scan: bail out early if failed to parse APIC ID for CPU) emits an error message if ACPI processor driver fails to query APIC ID for the CPU. Originally it's designed to catch BIOS bugs for CPU hot-addition. But it accidently reveals another type of BIOS bug that: 1) BIOS implements ACPI objects for all possible instead of present CPUs. (It's valid to do that per ACPI specification.) 2) BIOS doesn't implement the _STA method for CPU objects. OSPM assumes that all CPU objects are present and functioning and attempts to use those CPU objects for CPU enumeration, which then triggers the error message. According to ACPI spec, BIOS should implement _STA for those absent CPUs at least. Though it's a BIOS bug in essential, there are some BIOSes in the fields which are implmented in this way. So reduce the log level from ERR to DEBUG to accommodate these existing BIOSes. Fixes: b981513f806d (ACPI / scan: bail out early if failed to parse APIC ID for CPU) Reported-and-tested-by: Jörg Otte Signed-off-by: Jiang Liu [rjw: Changelog] Signed-off-by: Rafael J. Wysocki --- drivers/acpi/acpi_processor.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'drivers/acpi') diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c index 6ce71b0..21c0856 100644 --- a/drivers/acpi/acpi_processor.c +++ b/drivers/acpi/acpi_processor.c @@ -261,7 +261,7 @@ static int acpi_processor_get_info(struct acpi_device *device) apic_id = acpi_get_apicid(pr->handle, device_declaration, pr->acpi_id); if (apic_id < 0) { - acpi_handle_err(pr->handle, "failed to get CPU APIC ID.\n"); + acpi_handle_debug(pr->handle, "failed to get CPU APIC ID.\n"); return -ENODEV; } pr->apic_id = apic_id; -- cgit v1.1 From 79c0373f3e847309f4f33d23f2bf088ee3b1ac34 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Mon, 27 Jan 2014 23:10:24 +0100 Subject: ACPI / PM: Use ACPI_COMPANION() to get ACPI companions of devices The ACPI device PM code in device_pm.c uses a special function, acpi_dev_pm_get_node(), to obtain an ACPI companion object of a given device. However, that is not necessary any more after recent changes that introduced the ACPI_COMPANION() macro serving exactly the same purpose, but working in a much more straightforward way. For this reason, drop acpi_dev_pm_get_node() and use ACPI_COMPANION() instead of it everywhere. Signed-off-by: Rafael J. Wysocki Reviewed-by: Mika Westerberg --- drivers/acpi/device_pm.c | 24 ++++++------------------ 1 file changed, 6 insertions(+), 18 deletions(-) (limited to 'drivers/acpi') diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c index b3480cf..c14aa9a 100644 --- a/drivers/acpi/device_pm.c +++ b/drivers/acpi/device_pm.c @@ -713,18 +713,6 @@ int acpi_pm_device_sleep_wake(struct device *dev, bool enable) #endif /* CONFIG_PM_SLEEP */ /** - * acpi_dev_pm_get_node - Get ACPI device node for the given physical device. - * @dev: Device to get the ACPI node for. - */ -struct acpi_device *acpi_dev_pm_get_node(struct device *dev) -{ - acpi_handle handle = ACPI_HANDLE(dev); - struct acpi_device *adev; - - return handle && !acpi_bus_get_device(handle, &adev) ? adev : NULL; -} - -/** * acpi_dev_pm_low_power - Put ACPI device into a low-power state. * @dev: Device to put into a low-power state. * @adev: ACPI device node corresponding to @dev. @@ -764,7 +752,7 @@ static int acpi_dev_pm_full_power(struct acpi_device *adev) */ int acpi_dev_runtime_suspend(struct device *dev) { - struct acpi_device *adev = acpi_dev_pm_get_node(dev); + struct acpi_device *adev = ACPI_COMPANION(dev); bool remote_wakeup; int error; @@ -795,7 +783,7 @@ EXPORT_SYMBOL_GPL(acpi_dev_runtime_suspend); */ int acpi_dev_runtime_resume(struct device *dev) { - struct acpi_device *adev = acpi_dev_pm_get_node(dev); + struct acpi_device *adev = ACPI_COMPANION(dev); int error; if (!adev) @@ -848,7 +836,7 @@ EXPORT_SYMBOL_GPL(acpi_subsys_runtime_resume); */ int acpi_dev_suspend_late(struct device *dev) { - struct acpi_device *adev = acpi_dev_pm_get_node(dev); + struct acpi_device *adev = ACPI_COMPANION(dev); u32 target_state; bool wakeup; int error; @@ -880,7 +868,7 @@ EXPORT_SYMBOL_GPL(acpi_dev_suspend_late); */ int acpi_dev_resume_early(struct device *dev) { - struct acpi_device *adev = acpi_dev_pm_get_node(dev); + struct acpi_device *adev = ACPI_COMPANION(dev); int error; if (!adev) @@ -971,7 +959,7 @@ static struct dev_pm_domain acpi_general_pm_domain = { */ int acpi_dev_pm_attach(struct device *dev, bool power_on) { - struct acpi_device *adev = acpi_dev_pm_get_node(dev); + struct acpi_device *adev = ACPI_COMPANION(dev); if (!adev) return -ENODEV; @@ -1003,7 +991,7 @@ EXPORT_SYMBOL_GPL(acpi_dev_pm_attach); */ void acpi_dev_pm_detach(struct device *dev, bool power_off) { - struct acpi_device *adev = acpi_dev_pm_get_node(dev); + struct acpi_device *adev = ACPI_COMPANION(dev); if (adev && dev->pm_domain == &acpi_general_pm_domain) { dev->pm_domain = NULL; -- cgit v1.1 From 481c13814a4ecc8305fb7c871067a73cafd09d07 Mon Sep 17 00:00:00 2001 From: Lv Zheng Date: Fri, 24 Jan 2014 08:49:51 +0800 Subject: ACPICA: Remove bool usage from ACPICA. The use of "bool" is not safe for ACPICA code where it is originally using a "BOOLEAN" defined as "unsigned char". This patch removes the only "bool" usage from kernel source tree to reduce the source code differences between Linux and ACPICA upstream. This patch is required by future acpidump release automation. Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki --- drivers/acpi/acpica/acglobal.h | 2 +- drivers/acpi/sysfs.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) (limited to 'drivers/acpi') diff --git a/drivers/acpi/acpica/acglobal.h b/drivers/acpi/acpica/acglobal.h index 24db8e1..4ed1aa3 100644 --- a/drivers/acpi/acpica/acglobal.h +++ b/drivers/acpi/acpica/acglobal.h @@ -108,7 +108,7 @@ u8 ACPI_INIT_GLOBAL(acpi_gbl_use_default_register_widths, TRUE); /* * Optionally enable output from the AML Debug Object. */ -bool ACPI_INIT_GLOBAL(acpi_gbl_enable_aml_debug_object, FALSE); +u8 ACPI_INIT_GLOBAL(acpi_gbl_enable_aml_debug_object, FALSE); /* * Optionally copy the entire DSDT to local memory (instead of simply diff --git a/drivers/acpi/sysfs.c b/drivers/acpi/sysfs.c index 6dbc3ca..3e0b54f 100644 --- a/drivers/acpi/sysfs.c +++ b/drivers/acpi/sysfs.c @@ -226,7 +226,7 @@ module_param_call(trace_state, param_set_trace_state, param_get_trace_state, /* /sys/modules/acpi/parameters/aml_debug_output */ module_param_named(aml_debug_output, acpi_gbl_enable_aml_debug_object, - bool, 0644); + byte, 0644); MODULE_PARM_DESC(aml_debug_output, "To enable/disable the ACPI Debug Object output."); -- cgit v1.1 From 49a12877d2777cadcb838981c3c4f5a424aef310 Mon Sep 17 00:00:00 2001 From: Mark Brown Date: Mon, 27 Jan 2014 00:32:14 +0000 Subject: ACPI / init: Flag use of ACPI and ACPI idioms for power supplies to regulator API 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 Cc: All applicable Signed-off-by: Rafael J. Wysocki --- drivers/acpi/bus.c | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'drivers/acpi') diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c index 0710004..296bec8 100644 --- a/drivers/acpi/bus.c +++ b/drivers/acpi/bus.c @@ -33,6 +33,7 @@ #include #include #include +#include #ifdef CONFIG_X86 #include #endif @@ -576,6 +577,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: -- cgit v1.1 From a951c773bc39677ef3fa42814be7f5218a3100b2 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Mon, 27 Jan 2014 23:08:09 +0100 Subject: ACPI / scan: Clear match_driver flag in acpi_bus_trim() Drivers should not bind to struct acpi_device objects that acpi_bus_trim() has been called for, so make that function clear flags.match_driver for those objects. If that is not done, an ACPI driver may theoretically try to operate a device that is not physically present. Fixes: 202317a573b2 (ACPI / scan: Add acpi_device objects for all device nodes in the namespace) Signed-off-by: Rafael J. Wysocki Acked-by: Toshi Kani --- drivers/acpi/scan.c | 1 + 1 file changed, 1 insertion(+) (limited to 'drivers/acpi') diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c index c0f57ff..089dc40 100644 --- a/drivers/acpi/scan.c +++ b/drivers/acpi/scan.c @@ -2044,6 +2044,7 @@ void acpi_bus_trim(struct acpi_device *adev) list_for_each_entry_reverse(child, &adev->children, node) acpi_bus_trim(child); + adev->flags.match_driver = false; if (handler) { if (handler->detach) handler->detach(adev); -- cgit v1.1