kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-11-04 19:54:59 +00:00
Code Issues Releases Packages Activity
linux/drivers/acpi/processor_core.c

206 lines
4.9 KiB
Raw Normal View History

ACPI: processor: unify arch_acpi_processor_cleanup_pdc The x86 and ia64 implementations of the function in $subject are exactly the same. Also, since the arch-specific implementations of setting _PDC have been completely hollowed out, remove the empty shells. Cc: Tony Luck <tony.luck@intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-12-20 12:19:34 -07:00
acpi: add export.h to files using THIS_MODULE/EXPORT_SYMBOL These files were relying on module.h to come in via the path in an include/acpi header file, but we don't want to have instances of module.h being included from include/* files if it can be avoided. Have the files include export.h instead. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-10-26 16:22:14 -04:00
ACPI: Clean up inclusions of ACPI header files Replace direct inclusions of <acpi/acpi.h>, <acpi/acpi_bus.h> and <acpi/acpi_drivers.h>, which are incorrect, with <linux/acpi.h> inclusions and remove some inclusions of those files that aren't necessary. First of all, <acpi/acpi.h>, <acpi/acpi_bus.h> and <acpi/acpi_drivers.h> should not be included directly from any files that are built for CONFIG_ACPI unset, because that generally leads to build warnings about undefined symbols in !CONFIG_ACPI builds. For CONFIG_ACPI set, <linux/acpi.h> includes those files and for CONFIG_ACPI unset it provides stub ACPI symbols to be used in that case. Second, there are ordering dependencies between those files that always have to be met. Namely, it is required that <acpi/acpi_bus.h> be included prior to <acpi/acpi_drivers.h> so that the acpi_pci_root declarations the latter depends on are always there. And <acpi/acpi.h> which provides basic ACPICA type declarations should always be included prior to any other ACPI headers in CONFIG_ACPI builds. That also is taken care of including <linux/acpi.h> as appropriate. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Tony Luck <tony.luck@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> (drivers/pci stuff) Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> (Xen stuff) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-12-03 08:49:16 +08:00
ACPI: processor: call _PDC early We discovered that at least one machine (HP Envy), methods in the DSDT attempt to call external methods defined in a dynamically loaded SSDT. Unfortunately, the DSDT methods we are trying to call are part of the EC initialization, which happens very early, and the the dynamic SSDT is only loaded when a processor _PDC method runs much later. This results in namespace lookup errors for the (as of yet) undefined methods. Since Windows doesn't have any issues with this machine, we take it as a hint that they must be evaluating _PDC much earlier than we are. Thus, the proper thing for Linux to do should be to match the Windows implementation more closely. Provide a mechanism to call _PDC before we enable the EC. Doing so loads the dynamic tables, and allows the EC to be enabled correctly. The ACPI processor driver will still evaluate _PDC in its .add() method to cover the hotplug case. Resolves: http://bugzilla.kernel.org/show_bug.cgi?id=14824 Cc: ming.m.lin@intel.com Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-12-20 12:19:09 -07:00
ACPI: processor: mv processor_pdc.c processor_core.c We've renamed the old processor_core.c to processor_driver.c, to convey the idea that it can be built modular and has driver-like bits. Now let's re-create a processor_core.c for the bits needed statically by the rest of the kernel. The contents of processor_pdc.c are a good starting spot, so let's just rename that file and complete our three card monte. Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-02-22 12:11:14 -07:00
ACPI: processor: call _PDC early We discovered that at least one machine (HP Envy), methods in the DSDT attempt to call external methods defined in a dynamically loaded SSDT. Unfortunately, the DSDT methods we are trying to call are part of the EC initialization, which happens very early, and the the dynamic SSDT is only loaded when a processor _PDC method runs much later. This results in namespace lookup errors for the (as of yet) undefined methods. Since Windows doesn't have any issues with this machine, we take it as a hint that they must be evaluating _PDC much earlier than we are. Thus, the proper thing for Linux to do should be to match the Windows implementation more closely. Provide a mechanism to call _PDC before we enable the EC. Doing so loads the dynamic tables, and allows the EC to be enabled correctly. The ACPI processor driver will still evaluate _PDC in its .add() method to cover the hotplug case. Resolves: http://bugzilla.kernel.org/show_bug.cgi?id=14824 Cc: ming.m.lin@intel.com Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-12-20 12:19:09 -07:00
ACPI: processor: move acpi_get_cpuid into processor_core.c Enumerating processors (via MADT/_MAT) belongs in the processor core, which is always built-in, rather than living in the processor driver which may not be built. Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-02-22 12:11:24 -07:00
ACPI: processor: refactor internal map_lapic_id() Untangle the if() statement a little for readability. Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-02-22 12:11:44 -07:00
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 <hanjun.guo@linaro.org> [rjw: Changelog] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-01-17 12:37:02 +08:00
ACPI: processor: refactor internal map_lapic_id() Untangle the if() statement a little for readability. Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-02-22 12:11:44 -07:00
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 <hanjun.guo@linaro.org> [rjw: Changelog] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-01-17 12:37:02 +08:00
ACPI: processor: refactor internal map_lapic_id() Untangle the if() statement a little for readability. Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-02-22 12:11:44 -07:00
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 <hanjun.guo@linaro.org> [rjw: Changelog] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-01-17 12:37:02 +08:00
ACPI: processor: move acpi_get_cpuid into processor_core.c Enumerating processors (via MADT/_MAT) belongs in the processor core, which is always built-in, rather than living in the processor driver which may not be built. Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-02-22 12:11:24 -07:00
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 <hanjun.guo@linaro.org> [rjw: Changelog] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-01-17 12:37:02 +08:00
ACPI: processor: move acpi_get_cpuid into processor_core.c Enumerating processors (via MADT/_MAT) belongs in the processor core, which is always built-in, rather than living in the processor driver which may not be built. Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-02-22 12:11:24 -07:00
ACPI: processor: refactor internal map_x2apic_id() Untangle the nested if conditions to make this function look more similar to the other map_*apic_id() functions. Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-02-22 12:11:50 -07:00
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 <hanjun.guo@linaro.org> [rjw: Changelog] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-01-17 12:37:02 +08:00
ACPI: processor: move acpi_get_cpuid into processor_core.c Enumerating processors (via MADT/_MAT) belongs in the processor core, which is always built-in, rather than living in the processor driver which may not be built. Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-02-22 12:11:24 -07:00
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 <hanjun.guo@linaro.org> [rjw: Changelog] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-01-17 12:37:02 +08:00
ACPI: processor: move acpi_get_cpuid into processor_core.c Enumerating processors (via MADT/_MAT) belongs in the processor core, which is always built-in, rather than living in the processor driver which may not be built. Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-02-22 12:11:24 -07:00
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 <hanjun.guo@linaro.org> [rjw: Changelog] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-01-17 12:37:02 +08:00
ACPI: processor: move acpi_get_cpuid into processor_core.c Enumerating processors (via MADT/_MAT) belongs in the processor core, which is always built-in, rather than living in the processor driver which may not be built. Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-02-22 12:11:24 -07:00
ACPI: processor: refactor internal map_lsapic_id() Un-nest the if statements for readability. Remove comments that re-state the obvious. Change the control flow so that we no longer need a temp variable. Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-02-22 12:11:55 -07:00
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 <hanjun.guo@linaro.org> [rjw: Changelog] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-01-17 12:37:02 +08:00
ACPI: processor: refactor internal map_lsapic_id() Un-nest the if statements for readability. Remove comments that re-state the obvious. Change the control flow so that we no longer need a temp variable. Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-02-22 12:11:55 -07:00
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 <hanjun.guo@linaro.org> [rjw: Changelog] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-01-17 12:37:02 +08:00
ACPI: processor: move acpi_get_cpuid into processor_core.c Enumerating processors (via MADT/_MAT) belongs in the processor core, which is always built-in, rather than living in the processor driver which may not be built. Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-02-22 12:11:24 -07:00
ACPI: processor: refactor internal map_lsapic_id() Un-nest the if statements for readability. Remove comments that re-state the obvious. Change the control flow so that we no longer need a temp variable. Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-02-22 12:11:55 -07:00
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 <hanjun.guo@linaro.org> [rjw: Changelog] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-01-17 12:37:02 +08:00
ACPI: processor: move acpi_get_cpuid into processor_core.c Enumerating processors (via MADT/_MAT) belongs in the processor core, which is always built-in, rather than living in the processor driver which may not be built. Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-02-22 12:11:24 -07:00
ACPI: processor: push file static MADT pointer into internal map_madt_entry() There's no real need for a pointer to the MADT to be global. The only function who uses it is map_madt_entry. This allows us to remove some more ugly #ifdefs. Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-02-22 12:12:00 -07:00
ACPI: processor: move acpi_get_cpuid into processor_core.c Enumerating processors (via MADT/_MAT) belongs in the processor core, which is always built-in, rather than living in the processor driver which may not be built. Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-02-22 12:11:24 -07:00
ACPI: processor: push file static MADT pointer into internal map_madt_entry() There's no real need for a pointer to the MADT to be global. The only function who uses it is map_madt_entry. This allows us to remove some more ugly #ifdefs. Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-02-22 12:12:00 -07:00
ACPI: processor: move acpi_get_cpuid into processor_core.c Enumerating processors (via MADT/_MAT) belongs in the processor core, which is always built-in, rather than living in the processor driver which may not be built. Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-02-22 12:11:24 -07:00
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 <hanjun.guo@linaro.org> [rjw: Changelog] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-01-17 12:37:02 +08:00
ACPI: processor: move acpi_get_cpuid into processor_core.c Enumerating processors (via MADT/_MAT) belongs in the processor core, which is always built-in, rather than living in the processor driver which may not be built. Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-02-22 12:11:24 -07:00
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 <hanjun.guo@linaro.org> [rjw: Changelog] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-01-17 12:37:02 +08:00
ACPI: processor: move acpi_get_cpuid into processor_core.c Enumerating processors (via MADT/_MAT) belongs in the processor core, which is always built-in, rather than living in the processor driver which may not be built. Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-02-22 12:11:24 -07:00
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 <hanjun.guo@linaro.org> [rjw: Changelog] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-01-17 12:37:02 +08:00
ACPI: processor: move acpi_get_cpuid into processor_core.c Enumerating processors (via MADT/_MAT) belongs in the processor core, which is always built-in, rather than living in the processor driver which may not be built. Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-02-22 12:11:24 -07:00
ACPI / processor: Make it possible to get local x2apic id via _MAT Logical processors with APIC ID values of 255 and greater are required to have a Processor Device object and must convey the processor's APIC information to OSPM using the Processor Local X2APIC structure, but not until ACPI 5.1, X2APIC structure was not supported in _MAT method. _MAT is needed for CPU hotplug and system with more than 255 CPUs will definitely need X2APIC structure, so add its support in map_mat_entry() to make it possible to get local x2apic id via _MAT based on ACPI 5.1. Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-07-29 11:27:50 +08:00
ACPI: processor: move acpi_get_cpuid into processor_core.c Enumerating processors (via MADT/_MAT) belongs in the processor core, which is always built-in, rather than living in the processor driver which may not be built. Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-02-22 12:11:24 -07:00
ACPI / processor: Remove redundant NULL check before kfree kfree() on a NULL pointer is a no-op, so remove a redundant NULL pointer check in map_mat_entry(). [rjw: Changelog] Signed-off-by: Syam Sidhardhan <s.syam@samsung.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-02-24 23:12:53 +00:00
ACPI: processor: move acpi_get_cpuid into processor_core.c Enumerating processors (via MADT/_MAT) belongs in the processor core, which is always built-in, rather than living in the processor driver which may not be built. Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-02-22 12:11:24 -07:00
ACPI / processor: Introduce apic_id in struct processor to save parsed APIC id For cpu hot add, we evaluate _MAT or parse MADT twice to get APIC id, here is the code logic: acpi_processor_add() acpi_processor_get_info() acpi_get_cpuid() will evaluate _MAT or parse MADT; acpi_processor_hotadd_init() acpi_map_lsapic() will evaluate _MAT again; This can be done more effectively, this patch introduces apic_id in struct processor to save parsed APIC id, and then we can use it and remove the duplicated _MAT evaluation. Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-09-02 11:57:34 +08:00
ACPI: processor: move acpi_get_cpuid into processor_core.c Enumerating processors (via MADT/_MAT) belongs in the processor core, which is always built-in, rather than living in the processor driver which may not be built. Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-02-22 12:11:24 -07:00
ACPI / processor: Introduce apic_id in struct processor to save parsed APIC id For cpu hot add, we evaluate _MAT or parse MADT twice to get APIC id, here is the code logic: acpi_processor_add() acpi_processor_get_info() acpi_get_cpuid() will evaluate _MAT or parse MADT; acpi_processor_hotadd_init() acpi_map_lsapic() will evaluate _MAT again; This can be done more effectively, this patch introduces apic_id in struct processor to save parsed APIC id, and then we can use it and remove the duplicated _MAT evaluation. Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-09-02 11:57:34 +08:00
ACPI: processor: move acpi_get_cpuid into processor_core.c Enumerating processors (via MADT/_MAT) belongs in the processor core, which is always built-in, rather than living in the processor driver which may not be built. Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-02-22 12:11:24 -07:00
ACPI / processor: Introduce apic_id in struct processor to save parsed APIC id For cpu hot add, we evaluate _MAT or parse MADT twice to get APIC id, here is the code logic: acpi_processor_add() acpi_processor_get_info() acpi_get_cpuid() will evaluate _MAT or parse MADT; acpi_processor_hotadd_init() acpi_map_lsapic() will evaluate _MAT again; This can be done more effectively, this patch introduces apic_id in struct processor to save parsed APIC id, and then we can use it and remove the duplicated _MAT evaluation. Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-09-02 11:57:34 +08:00
ACPI: processor: fix acpi_get_cpuid for UP processor For UP processor, it is likely that no _MAT method or MADT table defined. So currently acpi_get_cpuid(...) always return -1 for UP processor. This is wrong. It should return valid value for CPU0. In the other hand, BIOS may define multiple CPU handles even for UP processor, for example Scope (_PR) { Processor (CPU0, 0x00, 0x00000410, 0x06) {} Processor (CPU1, 0x01, 0x00000410, 0x06) {} Processor (CPU2, 0x02, 0x00000410, 0x06) {} Processor (CPU3, 0x03, 0x00000410, 0x06) {} } We should only return valid value for CPU0's acpi handle. And return invalid value for others. http://marc.info/?t=132329819900003&r=1&w=2 Cc: stable@vger.kernel.org Reported-and-tested-by: wallak@free.fr Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2011-12-13 09:36:03 +08:00
cpufreq / ACPI: Fix not loading acpi-cpufreq driver regression Commit d640113fe80e45ebd4a5b420b introduced a regression on SMP systems where the processor core with ACPI id zero is disabled (typically should be the case because of hyperthreading). The regression got spread through stable kernels. On 3.0.X it got introduced via 3.0.18. Such platforms may be rare, but do exist. Look out for a disabled processor with acpi_id 0 in dmesg: ACPI: LAPIC (acpi_id[0x00] lapic_id[0x10] disabled) This problem has been observed on a: HP Proliant BL280c G6 blade This patch restricts the introduced workaround to platforms with nr_cpu_ids <= 1. Signed-off-by: Thomas Renninger <trenn@suse.de> CC: stable@vger.kernel.org Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2012-07-12 12:24:33 +02:00
ACPI: processor: fix acpi_get_cpuid for UP processor For UP processor, it is likely that no _MAT method or MADT table defined. So currently acpi_get_cpuid(...) always return -1 for UP processor. This is wrong. It should return valid value for CPU0. In the other hand, BIOS may define multiple CPU handles even for UP processor, for example Scope (_PR) { Processor (CPU0, 0x00, 0x00000410, 0x06) {} Processor (CPU1, 0x01, 0x00000410, 0x06) {} Processor (CPU2, 0x02, 0x00000410, 0x06) {} Processor (CPU3, 0x03, 0x00000410, 0x06) {} } We should only return valid value for CPU0's acpi handle. And return invalid value for others. http://marc.info/?t=132329819900003&r=1&w=2 Cc: stable@vger.kernel.org Reported-and-tested-by: wallak@free.fr Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2011-12-13 09:36:03 +08:00
cpufreq / ACPI: Fix not loading acpi-cpufreq driver regression Commit d640113fe80e45ebd4a5b420b introduced a regression on SMP systems where the processor core with ACPI id zero is disabled (typically should be the case because of hyperthreading). The regression got spread through stable kernels. On 3.0.X it got introduced via 3.0.18. Such platforms may be rare, but do exist. Look out for a disabled processor with acpi_id 0 in dmesg: ACPI: LAPIC (acpi_id[0x00] lapic_id[0x10] disabled) This problem has been observed on a: HP Proliant BL280c G6 blade This patch restricts the introduced workaround to platforms with nr_cpu_ids <= 1. Signed-off-by: Thomas Renninger <trenn@suse.de> CC: stable@vger.kernel.org Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2012-07-12 12:24:33 +02:00
ACPI: processor: fix acpi_get_cpuid for UP processor For UP processor, it is likely that no _MAT method or MADT table defined. So currently acpi_get_cpuid(...) always return -1 for UP processor. This is wrong. It should return valid value for CPU0. In the other hand, BIOS may define multiple CPU handles even for UP processor, for example Scope (_PR) { Processor (CPU0, 0x00, 0x00000410, 0x06) {} Processor (CPU1, 0x01, 0x00000410, 0x06) {} Processor (CPU2, 0x02, 0x00000410, 0x06) {} Processor (CPU3, 0x03, 0x00000410, 0x06) {} } We should only return valid value for CPU0's acpi handle. And return invalid value for others. http://marc.info/?t=132329819900003&r=1&w=2 Cc: stable@vger.kernel.org Reported-and-tested-by: wallak@free.fr Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2011-12-13 09:36:03 +08:00
ACPI: processor: move acpi_get_cpuid into processor_core.c Enumerating processors (via MADT/_MAT) belongs in the processor core, which is always built-in, rather than living in the processor driver which may not be built. Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-02-22 12:11:24 -07:00
ACPI: processor: fix processor_physically_present in UP kernel Usually, there are multiple processors defined in ACPI table, for example Scope (_PR) { Processor (CPU0, 0x00, 0x00000410, 0x06) {} Processor (CPU1, 0x01, 0x00000410, 0x06) {} Processor (CPU2, 0x02, 0x00000410, 0x06) {} Processor (CPU3, 0x03, 0x00000410, 0x06) {} } processor_physically_present(...) will be called to check whether those processors are physically present. Currently we have below codes in processor_physically_present, cpuid = acpi_get_cpuid(...); if ((cpuid == -1) && (num_possible_cpus() > 1)) return false; return true; In UP kernel, acpi_get_cpuid(...) always return -1 and num_possible_cpus() always return 1, so processor_physically_present(...) always returns true for all passed in processor handles. This is wrong for UP processor or SMP processor running UP kernel. This patch removes the !SMP version of acpi_get_cpuid(), so both UP and SMP kernel use the same acpi_get_cpuid function. And for UP kernel, only processor 0 is valid. https://bugzilla.kernel.org/show_bug.cgi?id=16548 https://bugzilla.kernel.org/show_bug.cgi?id=16357 Tested-by: Anton Kochkov <anton.kochkov@gmail.com> Tested-by: Ambroz Bizjak <ambrop7@gmail.com> Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2011-05-16 09:11:00 +08:00
ACPI: processor: move acpi_get_cpuid into processor_core.c Enumerating processors (via MADT/_MAT) belongs in the processor core, which is always built-in, rather than living in the processor driver which may not be built. Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-02-22 12:11:24 -07:00
ACPI: processor: fix processor_physically_present in UP kernel Usually, there are multiple processors defined in ACPI table, for example Scope (_PR) { Processor (CPU0, 0x00, 0x00000410, 0x06) {} Processor (CPU1, 0x01, 0x00000410, 0x06) {} Processor (CPU2, 0x02, 0x00000410, 0x06) {} Processor (CPU3, 0x03, 0x00000410, 0x06) {} } processor_physically_present(...) will be called to check whether those processors are physically present. Currently we have below codes in processor_physically_present, cpuid = acpi_get_cpuid(...); if ((cpuid == -1) && (num_possible_cpus() > 1)) return false; return true; In UP kernel, acpi_get_cpuid(...) always return -1 and num_possible_cpus() always return 1, so processor_physically_present(...) always returns true for all passed in processor handles. This is wrong for UP processor or SMP processor running UP kernel. This patch removes the !SMP version of acpi_get_cpuid(), so both UP and SMP kernel use the same acpi_get_cpuid function. And for UP kernel, only processor 0 is valid. https://bugzilla.kernel.org/show_bug.cgi?id=16548 https://bugzilla.kernel.org/show_bug.cgi?id=16357 Tested-by: Anton Kochkov <anton.kochkov@gmail.com> Tested-by: Ambroz Bizjak <ambrop7@gmail.com> Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2011-05-16 09:11:00 +08:00
ACPI: processor: move acpi_get_cpuid into processor_core.c Enumerating processors (via MADT/_MAT) belongs in the processor core, which is always built-in, rather than living in the processor driver which may not be built. Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-02-22 12:11:24 -07:00
ACPI / processor: Introduce apic_id in struct processor to save parsed APIC id For cpu hot add, we evaluate _MAT or parse MADT twice to get APIC id, here is the code logic: acpi_processor_add() acpi_processor_get_info() acpi_get_cpuid() will evaluate _MAT or parse MADT; acpi_processor_hotadd_init() acpi_map_lsapic() will evaluate _MAT again; This can be done more effectively, this patch introduces apic_id in struct processor to save parsed APIC id, and then we can use it and remove the duplicated _MAT evaluation. Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-09-02 11:57:34 +08:00
ACPI: processor: move acpi_get_cpuid into processor_core.c Enumerating processors (via MADT/_MAT) belongs in the processor core, which is always built-in, rather than living in the processor driver which may not be built. Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-02-22 12:11:24 -07:00