According commit d640113fe(ACPI: processor: fix acpi_get_cpuid for UP processor), Bios may not provide _MAT or MADT tables and acpi_get_apicid() always returns -1. For these cases, original code will pass apic_id with vaule of -1 to acpi_map_cpuid() and it will check the acpi_id. If acpi_id is equal to zero, ignores apic_id and return zero for CPU0. Commit b981513(ACPI / scan: bail out early if failed to parse APIC ID for CPU) changed the behavior. Return ENODEV when find apic_id is less than zero after calling acpi_get_apicid(). This causes acpi-cpufreq driver fails to be loaded on some machines. This patch is to fix it. Reference:https://bugzilla.kernel.org/show_bug.cgi?id=73781 Cc: stable@xxxxxxxxxxxxxxx v3.14 Reported-and-tested-by: KATO Hiroshi <katoh@xxxxxxxxxxxx> Reported-and-tested-by: Stuart Foster <smf.linux@xxxxxxxxxxxx> Signed-off-by: Lan Tianyu <tianyu.lan@xxxxxxxxx> --- drivers/acpi/acpi_processor.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c index c29c2c3..d55b603 100644 --- a/drivers/acpi/acpi_processor.c +++ b/drivers/acpi/acpi_processor.c @@ -260,10 +260,8 @@ 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) { + if (apic_id < 0) acpi_handle_debug(pr->handle, "failed to get CPU APIC ID.\n"); - return -ENODEV; - } pr->apic_id = apic_id; cpu_index = acpi_map_cpuid(pr->apic_id, pr->acpi_id); -- 1.8.4.rc0.1.g8f6a3e5.dirty -- 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
