summaryrefslogtreecommitdiffstats
path: root/drivers/acpi/tables.c
AgeCommit message (Collapse)AuthorFilesLines
2017-07-20ACPICA: Tables: Change table duplication check to be related to ↵Lv Zheng1-2/+2
acpi_gbl_verify_table_checksum ACPICA commit 3d837b5d4b1033942b4d91c7d3801a09c3157918 acpi_gbl_verify_table_checksum is used to avoid validating (mapping) an entire table in OS boot stage. 2nd "Reload" check in acpi_tb_install_standard_table() is prepared for the same purpose. So this patch combines them together using a renamed acpi_gbl_enable_table_validation flag. Lv Zheng. Link: https://github.com/acpica/acpica/commit/3d837b5d Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-05-01Merge branch 'x86-boot-for-linus' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 boot updates from Ingo Molnar: "The biggest changes in this cycle were: - reworking of the e820 code: separate in-kernel and boot-ABI data structures and apply a whole range of cleanups to the kernel side. No change in functionality. - enable KASLR by default: it's used by all major distros and it's out of the experimental stage as well. - ... misc fixes and cleanups" * 'x86-boot-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (63 commits) x86/KASLR: Fix kexec kernel boot crash when KASLR randomization fails x86/reboot: Turn off KVM when halting a CPU x86/boot: Fix BSS corruption/overwrite bug in early x86 kernel startup x86: Enable KASLR by default boot/param: Move next_arg() function to lib/cmdline.c for later reuse x86/boot: Fix Sparse warning by including required header file x86/boot/64: Rename start_cpu() x86/xen: Update e820 table handling to the new core x86 E820 code x86/boot: Fix pr_debug() API braindamage xen, x86/headers: Add <linux/device.h> dependency to <asm/xen/page.h> x86/boot/e820: Simplify e820__update_table() x86/boot/e820: Separate the E820 ABI structures from the in-kernel structures x86/boot/e820: Fix and clean up e820_type switch() statements x86/boot/e820: Rename the remaining E820 APIs to the e820__*() prefix x86/boot/e820: Remove unnecessary #include's x86/boot/e820: Rename e820_mark_nosave_regions() to e820__register_nosave_regions() x86/boot/e820: Rename e820_reserve_resources*() to e820__reserve_resources*() x86/boot/e820: Use bool in query APIs x86/boot/e820: Document e820__reserve_setup_data() x86/boot/e820: Clean up __e820__update_table() et al ...
2017-04-19ACPI / tables: Drop acpi_parse_entries() which is not usedBaoquan He1-16/+0
Function acpi_parse_entries() is not used any more and if necessary, acpi_table_parse_entries() can be used instead of it, so drop it. Signed-off-by: Baoquan He <bhe@redhat.com> [ rjw: Subject / changelog ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-01-28x86/boot/e820: Create coherent API function names for E820 range operationsIngo Molnar1-1/+1
We have these three related functions: extern void e820_add_region(u64 start, u64 size, int type); extern u64 e820_update_range(u64 start, u64 size, unsigned old_type, unsigned new_type); extern u64 e820_remove_range(u64 start, u64 size, unsigned old_type, int checktype); But it's not clear from the naming that they are 3 operations based around the same 'memory range' concept. Rename them to better signal this, and move the prototypes next to each other: extern void e820__range_add (u64 start, u64 size, int type); extern u64 e820__range_update(u64 start, u64 size, unsigned old_type, unsigned new_type); extern u64 e820__range_remove(u64 start, u64 size, unsigned old_type, int checktype); Note that this improved organization of the functions shows another problem that was easy to miss before: sometimes the E820 entry type is 'int', sometimes 'unsigned int' - but this will be fixed in a separate patch. No change in functionality. Cc: Alex Thorlton <athorlton@sgi.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Huang, Ying <ying.huang@intel.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Juergen Gross <jgross@suse.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Paul Jackson <pj@sgi.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Rafael J. Wysocki <rjw@sisk.pl> Cc: Tejun Heo <tj@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Wei Yang <richard.weiyang@gmail.com> Cc: Yinghai Lu <yinghai@kernel.org> Cc: linux-kernel@vger.kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-12-21ACPI / osl: Remove acpi_get_table_with_size()/early_acpi_os_unmap_memory() usersLv Zheng1-10/+7
This patch removes the users of the deprectated APIs: acpi_get_table_with_size() early_acpi_os_unmap_memory() The following APIs should be used instead of: acpi_get_table() acpi_put_table() The deprecated APIs are invented to be a replacement of acpi_get_table() during the early stage so that the early mapped pointer will not be stored in ACPICA core and thus the late stage acpi_get_table() won't return a wrong pointer. The mapping size is returned just because it is required by early_acpi_os_unmap_memory() to unmap the pointer during early stage. But as the mapping size equals to the acpi_table_header.length (see acpi_tb_init_table_descriptor() and acpi_tb_validate_table()), when such a convenient result is returned, driver code will start to use it instead of accessing acpi_table_header to obtain the length. Thus this patch cleans up the drivers by replacing returned table size with acpi_table_header.length, and should be a no-op. Reported-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-09-17ACPI / tables: Remove duplicated include from tables.cWei Yongjun1-1/+0
Remove duplicated include. Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-31ACPI / tables: do not report the number of entries ignored by ↵Al Stone1-2/+2
acpi_parse_entries() The function acpi_parse_entries_array() has a limiting parameter, max_entries, which tells the function to stop looking at subtables once that limit has been reached. If the limit is reached, it is reported. However, the logic is incorrect in that the loop to examine all subtables will always report that zero subtables have been ignored since it does not continue once the max_entries have been reached. One approach to fixing this would be to correct the logic so that all subtables are examined, even if we have hit the max_entries, but without executing all the callback functions. This could be risky since we cannot guarantee that no callback will ever have side effects that another callback depends on to work correctly. So, the simplest approach is to just remove the part of the error message that will always be incorrect. Signed-off-by: Al Stone <ahs3@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-31ACPI / tables: fix acpi_parse_entries_array() so it traverses all subtablesAl Stone1-3/+6
The acpi_parse_entries_array() function currently returns the very first time there is any error found by one of the callback functions, or if one of the callbacks returns a non-zero value. However, the ACPI subtables being traversed could still have valid entries that could be used by one of the callback functions. And, if the comments are correct, that is what should happen -- always traverse all of the subtables, calling as many of the callbacks as possible. This patch makes the function consistent with its description so that it will properly invoke all callbacks for all matching entries, for all subtables, instead of stopping abruptly as it does today. This does change the semantics of using acpi_parse_entries_array(). In examining all users of the function, none of them rely on the current behavior; that is, there appears to be no assumption that either all subtables are traversed and all callbacks invoked, or that the function will return immediately on any error from a callback. Each callback operates independently. Hence, there should be no functional change due to this change in semantics. Future patches being prepared will rely on this new behavior; indeed, they were written assuming the acpi_parse_entries_array() function operated as its comments describe. For example, a callback that counts the number of subtables of a specific type can now be assured that as many subtables as possible have been enumerated. Signed-off-by: Al Stone <ahs3@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-31ACPI / tables: fix incorrect counts returned by acpi_parse_entries_array()Al Stone1-1/+1
The static function acpi_parse_entries_array() is provided an array of type struct acpi_subtable_proc that has a callback function and a count. The count should reflect how many times the callback has been called. However, the current code only increments the 0th element of the array, regardless of the number of entries in the array, or which callback has been invoked. The result is that we know the total number of callbacks made but we cannot determine which callbacks were made, nor how often. The fix is to index into the array of structs and increment the proper counts. There is one place in the x86 code for acpi_parse_madt_lapic_entries() where the counts for each callback are used. If no LAPICs *and* no X2APICs are found, an ENODEV is supposed to be returned; as it stands, the count of X2APICs will always be zero, regardless of what is in the MADT. Should there be no LAPICs, ENODEV will be returned in error, if there are X2APICs in the MADT. Otherwise, there are no other functional consequences of the count being done as it currently is; all other uses simply check that the return value from acpi_parse_entries_array() or passed back via its callers is either non-zero, an error, or in one case just ignored. In future patches, I will also need these counts to be correct; I need to count the number of instances of subtables of certain types within the MADT to determine whether or not an ACPI IORT is required or not, and report when it is not present when it should be. Signed-off-by: Al Stone <ahs3@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-06-22ACPI / tables: move arch-specific symbol to asm/acpi.hAleksey Makarov1-1/+2
The constant that defines max phys address where the new upgraded ACPI table should be allocated is arch-specific. Move it to <asm/acpi.h> Signed-off-by: Aleksey Makarov <aleksey.makarov@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-06-22ACPI / tables: table upgrade: refactor function definitionsAleksey Makarov1-10/+4
Refer initrd_start, initrd_end directly from drivers/acpi/tables.c. This allows to use the table upgrade feature in architectures other than x86. Also this simplifies header files. The patch renames acpi_table_initrd_init() to acpi_table_upgrade() (what reflects the purpose of the function) and removes the unneeded wraps early_acpi_table_init() and early_initrd_acpi_init(). Signed-off-by: Aleksey Makarov <aleksey.makarov@linaro.org> Acked-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-06-22ACPI / tables: table upgrade: use cacheable map for tablesAleksey Makarov1-3/+3
The new memory allocated in acpi_table_initrd_init() is used to copy the upgraded tables to it. So it should be mapped with early_memunmap() instead of early_ioremap(). This is critical for ARM. Signed-off-by: Aleksey Makarov <aleksey.makarov@linaro.org> Acked-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-06ACPI / tables: Fix DSDT override mechanismRafael J. Wysocki1-0/+4
Commit 5ae74f2cc2f1 (ACPI / tables: Move table override mechanisms to tables.c) forgot to move the CONFIG_ACPI_CUSTOM_DSDT_FILE inclusion directive from osl.c to tables.c. Fix that. Fixes: 5ae74f2cc2f1 (ACPI / tables: Move table override mechanisms to tables.c) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Lv Zheng <lv.zheng@intel.com>
2016-04-18ACPI / tables: Convert initrd table override to table upgrade mechanismLv Zheng1-14/+34
This patch converts the initrd table override mechanism to the table upgrade mechanism by restricting its usage to the tables released with compatibility and more recent revision. This use case has been encouraged by the ACPI specification: 1. OEMID: An OEM-supplied string that identifies the OEM. 2. OEM Table ID: An OEM-supplied string that the OEM uses to identify the particular data table. This field is particularly useful when defining a definition block to distinguish definition block functions. OEM assigns each dissimilar table a new OEM Table Id. 3. OEM Revision: An OEM-supplied revision number. Larger numbers are assumed to be newer revisions. For OEMs, good practices will ensure consistency when assigning OEMID and OEM Table ID fields in any table. The intent of these fields is to allow for a binary control system that support services can use. Because many support function can be automated, it is useful when a tool can programatically determine which table release is a compatible and more recent revision of a prior table on the same OEMID and OEM Table ID. The facility can now be used by the vendors to upgrade wrong tables for bug fixing purpose, thus lockdep disabling taint is not suitable for it and it should be a default 'y' option to implement the spec encouraged use case. Note that, by implementing table upgrade inside of ACPICA itself, it is possible to remove acpi_table_initrd_override() and tables can be upgraded by acpi_install_table() automatically. Though current ACPICA impelentation hasn't implemented this, this patched changes the table flag setting timing to allow this to be implemented in ACPICA without changing the code here. Documentation of initrd override mechanism is upgraded accordingly. Original-by: Octavian Purdila <octavian.purdila@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-04-18ACPI / tables: Move table override mechanisms to tables.cLv Zheng1-1/+291
This patch moves acpi_os_table_override() and acpi_os_physical_table_override() to tables.c. Along with the mechanisms, acpi_initrd_initialize_tables() is also moved to tables.c to form a static function. The following functions are renamed according to this change: 1. acpi_initrd_override() -> renamed to early_acpi_table_init(), which invokes acpi_table_initrd_init() 2. acpi_os_physical_table_override() -> which invokes acpi_table_initrd_override() 3. acpi_initialize_initrd_tables() -> renamed to acpi_table_initrd_scan() Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-03-14Merge branches 'acpi-ec', 'acpi-fan', 'acpi-video' and 'acpi-misc'Rafael J. Wysocki1-0/+10
* acpi-ec: ACPI / EC: Deny write access unless requested by module param * acpi-fan: ACPI / fan: Make struct dev_pm_ops const * acpi-video: ACPI / video: remove unused device_decode array * acpi-misc: ACPI / util: remove redundant check if element is NULL ACPI: Add acpi_force_32bit_fadt_addr option to force 32 bit FADT addresses drivers/acpi: make pmic/intel_pmic_crc.c explicitly non-modular drivers/acpi: make apei/ghes.c more explicitly non-modular drivers/acpi: make bgrt driver explicitly non-modular
2016-03-09ACPI / OSL: Add support to install tables via initrdLv Zheng1-0/+2
This patch adds support to install tables from initrd. If a table in the initrd wasn't used by the override mechanism, the table would be installed after initializing all RSDT/XSDT tables. Link: https://lkml.org/lkml/2014/2/28/368 Reported-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-03-09ACPI: Add acpi_force_32bit_fadt_addr option to force 32 bit FADT addressesColin Ian King1-0/+10
Some HP laptops seem to have invalid 64 bit FADT X_PM* addresses which are causing various boot issues. In these cases, it would be useful to force ACPI to use the valid legacy 32 bit equivalent PM addresses. Add a acpi_force_32bit_fadt_addr to set the ACPICA acpi_gbl_use32_bit_fadt_addresses to TRUE to force this override. Link: https://bugs.launchpad.net/bugs/1529381 Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-10-15ACPI / tables: test the correct variableDan Carpenter1-1/+2
The intent was to test "proc[i].handler" instead of "proc->handler". Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-10-15ACPI / tables: Add acpi_subtable_proc to ACPI table parsersLukasz Anaczkowski1-18/+75
ACPI subtable parsing needs to be extended to allow two or more handlers to be run in the same ACPI table walk, thus adding acpi_subtable_proc structure which stores () ACPI table id () handler that processes table () counter how many items has been processed and passing it to acpi_parse_entries_array() and acpi_table_parse_entries_array(). This is needed to fix CPU enumeration when APIC/X2APIC entries are interleaved. Signed-off-by: Lukasz Anaczkowski <lukasz.anaczkowski@intel.com> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com> Tested-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-07-08ACPI: Remove FSF mailing addressesJarkko Nikula1-4/+0
There is no need to carry potentially outdated Free Software Foundation mailing address in file headers since the COPYING file includes it. Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-03-25ACPI / table: Print GIC information when MADT is parsedHanjun Guo1-0/+22
When MADT is parsed, print GIC information as debug message: ACPI: GICC (acpi_id[0x0000] address[00000000e112f000] MPIDR[0x0] enabled) ACPI: GICC (acpi_id[0x0001] address[00000000e112f000] MPIDR[0x1] enabled) ... ACPI: GICC (acpi_id[0x0201] address[00000000e112f000] MPIDR[0x201] enabled) This debug information will be very helpful to bring up early systems to see if acpi_id and MPIDR are matched or not as spec defined. CC: Rafael J. Wysocki <rjw@rjwysocki.net> Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> Tested-by: Yijing Wang <wangyijing@huawei.com> Tested-by: Mark Langsdorf <mlangsdo@redhat.com> Tested-by: Jon Masters <jcm@redhat.com> Tested-by: Timur Tabi <timur@codeaurora.org> Tested-by: Robert Richter <rrichter@cavium.com> Acked-by: Robert Richter <rrichter@cavium.com> Acked-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Grant Likely <grant.likely@linaro.org> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org> Signed-off-by: Will Deacon <will.deacon@arm.com>
2015-03-25ACPI / table: Use pr_debug() instead of pr_info() for MADT table scanningHanjun Guo1-14/+16
For a normal 8 cpu sockets system, it will up to 240 cpu threads (Xeon E7 v2 family for now), and we need 240 entries for local apic or local x2apic in MADT table, so it will be much verbose information printed with a slow uart console when system booted, this will be even worse with large system with 16/32 cpu sockets. This patch just use pr_debug() instead of pr_info() for ioapic/iosapic, local apic/x2apic/sapic structures when scanning the MADT table to remove those verbose information, but leave other structures unchanged. CC: Rafael J Wysocki <rjw@rjwysocki.net> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Olof Johansson <olof@lixom.net> Acked-by: Grant Likely <grant.likely@linaro.org> Tested-by: Timur Tabi <timur@codeaurora.org> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Will Deacon <will.deacon@arm.com>
2014-11-27ACPI / table: Always count matched and successfully parsed entriesTomasz Nowicki1-1/+4
acpi_parse_entries() allows to traverse all available table entries (aka subtables) by passing max_entries parameter equal to 0, but since its count variable is only incremented if max_entries is not 0, the function always returns 0 for max_entries equal to 0. It would be more useful if it returned the number of entries matched instead, so make it increment count in that case too. Acked-by: Grant Likely <grant.likely@linaro.org> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-27ACPI / table: Add new function to get table entriesAshwin Chaugule1-19/+44
The acpi_table_parse() function has a callback that passes a pointer to a table_header. Add a new function which takes this pointer and parses its entries. This eliminates the need to re-traverse all the tables for each call. e.g. as in acpi_table_parse_madt() which is normally called after acpi_table_parse(). Acked-by: Grant Likely <grant.likely@linaro.org> Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-06-17ACPI: use kstrto*() instead of simple_strto*()Christoph Jaeger1-1/+2
simple_strto*() are obsolete; use kstrto*() instead. Add proper error checking. Signed-off-by: Christoph Jaeger <christophjaeger@linux.com> Acked-by: David Rientjes <rientjes@google.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-06-01ACPI: Fix x86 regression related to early mapping size limitationLv Zheng1-0/+23
The following warning message is triggered: WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:136 __early_ioremap+0x11f/0x1f2() Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 3.15.0-rc1-00017-g86dfc6f3-dirty #298 Hardware name: Intel Corporation S2600CP/S2600CP, BIOS SE5C600.86B.99.99.x036.091920111209 09/19/2011 0000000000000009 ffffffff81b75c40 ffffffff817c627b 0000000000000000 ffffffff81b75c78 ffffffff81067b5d 000000000000007b 8000000000000563 00000000b96b20dc 0000000000000001 ffffffffff300e0c ffffffff81b75c88 Call Trace: [<ffffffff817c627b>] dump_stack+0x45/0x56 [<ffffffff81067b5d>] warn_slowpath_common+0x7d/0xa0 [<ffffffff81067c3a>] warn_slowpath_null+0x1a/0x20 [<ffffffff81d4b9d5>] __early_ioremap+0x11f/0x1f2 [<ffffffff81d4bc5b>] early_ioremap+0x13/0x15 [<ffffffff81d2b8f3>] __acpi_map_table+0x13/0x18 [<ffffffff817b8d1a>] acpi_os_map_memory+0x26/0x14e [<ffffffff813ff018>] acpi_tb_acquire_table+0x42/0x70 [<ffffffff813ff086>] acpi_tb_validate_table+0x27/0x37 [<ffffffff813ff0e5>] acpi_tb_verify_table+0x22/0xd8 [<ffffffff813ff6a8>] acpi_tb_install_non_fixed_table+0x60/0x1c9 [<ffffffff81d61024>] acpi_tb_parse_root_table+0x218/0x26a [<ffffffff81d1b120>] ? early_idt_handlers+0x120/0x120 [<ffffffff81d610cd>] acpi_initialize_tables+0x57/0x59 [<ffffffff81d5f25d>] acpi_table_init+0x1b/0x99 [<ffffffff81d2bca0>] acpi_boot_table_init+0x1e/0x85 [<ffffffff81d23043>] setup_arch+0x99d/0xcc6 [<ffffffff81d1b120>] ? early_idt_handlers+0x120/0x120 [<ffffffff81d1bbbe>] start_kernel+0x8b/0x415 [<ffffffff81d1b120>] ? early_idt_handlers+0x120/0x120 [<ffffffff81d1b5ee>] x86_64_start_reservations+0x2a/0x2c [<ffffffff81d1b72e>] x86_64_start_kernel+0x13e/0x14d ---[ end trace 11ae599a1898f4e7 ]--- when installing the following table during early stage: ACPI: SSDT 0x00000000B9638018 07A0C4 (v02 INTEL S2600CP 00004000 INTL 20100331) The regression is caused by the size limitation of the x86 early IO mapping. The root cause is: 1. ACPICA doesn't split IO memory mapping and table mapping; 2. Linux x86 OSL implements acpi_os_map_memory() using a size limited fix-map mechanism during early boot stage, which is more suitable for only IO mappings. This patch fixes this issue by utilizing acpi_gbl_verify_table_checksum to disable the table mapping during early stage and enabling it again for the late stage. In this way, the normal code path is not affected. Then after the code related to the root cause is cleaned up, the early checksum verification can be easily re-enabled. A new boot parameter - acpi_force_table_verification is introduced for the platforms that require the checksum verification to stop loading bad tables. This fix also covers the checksum verification for the table overrides. Now large tables can also be overridden using the initrd override mechanism. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Reported-and-tested-by: Yuanhan Liu <yuanhan.liu@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-03-02ACPI / tables: Replace printk with pr_*Hanjun Guo1-73/+55
This patch just does some cleanup to replace printk with pr_*, and introduces pr_fmt() to remove all PREFIXs in tables.c, no functional change. Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-01-06ACPI / tables: Return proper error codes from acpi_table_parse() and fix ↵tangchen1-2/+3
comment. The comment about return value of acpi_table_parse() is incorrect. This patch fix it. Since all callers only check if the function succeeded or not, this patch simplifies the semantics by returning -errno for all failure cases. This will also simply the comment. As suggested by Toshi Kani <toshi.kani@hp.com>, also change the stub in linux/acpi.h to return -ENODEV. Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-01-06ACPI / tables: Check if id is NULL in acpi_table_parse()tangchen1-1/+1
strncmp() does not check if the params are NULL. In acpi_table_parse(), if @id is NULL, the kernel will panic. Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com> Acked-by: Toshi Kani <toshi.kani@hp.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-12-07ACPI / table: Replace '1' with specific error return valuesHanjun Guo1-2/+2
After commit 7f8f97c3cc (ACPI: acpi_table_parse() now returns success/fail, not count), acpi_table_parse() returns '1' when it is unable to find the table, but it should return a negative error code in that case. Make it return -ENODEV instead. Fix the same problem in acpi_table_init() analogously. Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> [rjw: Subject and changelog] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-01-11ACPICA: Cleanup table handler naming conflicts.Lv Zheng1-3/+3
This is a cosmetic patch only. Comparison of the resulting binary showed only line number differences. This patch does not affect the generation of the Linux binary. This patch decreases 44 lines of 20121114 divergence.diff. There are naming conflicts between Linux and ACPICA on table handlers. This patch cleans up this conflicts to reduce the source code diff between Linux and ACPICA. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-10-06ACPI: Harden acpi_table_parse_entries() against BIOS bugFenghua Yu1-4/+14
Parsing acpi table entries may fall into an infinite loop on a buggy BIOS which has entry length=0 in acpi table. Instead of kernel hang with few failure clue which leads to heavy lifting debug effort, this patch hardens kernel boot by booting into non NUMA mode. The debug info left in log buffer helps people identify the issue. Signed-off-by: Fenghua Yu <fenghua.yu@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-03-14ACPI: delete the "acpi=ht" boot optionLen Brown1-2/+2
acpi=ht was important in 2003 -- before ACPI was universally deployed and enabled by default in the major Linux distributions. At that time, there were a fair number of people who or chose to, or needed to, run with acpi=off, yet also wanted access to Hyper-threading. Today we find that many invocations of "acpi=ht" are accidental, and thus is it possible that it is doing more harm than good. In 2.6.34, we warn on invocation of acpi=ht. In 2.6.35, we delete the boot option. Signed-off-by: Len Brown <len.brown@intel.com>
2010-02-18ACPI: fix "acpi=ht" boot optionLen Brown1-2/+2
We broke "acpi=ht" in 2.6.32 by disabling MADT parsing for acpi=disabled. e5b8fc6ac158f65598f58dba2c0d52ba3b412f52 This also broke systems which invoked acpi=ht via DMI blacklist. acpi=ht is a really ugly hack, but restore it for those that still use it. http://bugzilla.kernel.org/show_bug.cgi?id=14886 Signed-off-by: Len Brown <len.brown@intel.com>
2009-08-28ACPI: check acpi_disabled in acpi_table_parse() and acpi_table_parse_entries()Len Brown1-0/+6
Allow consumers of the acpi_table_parse()/acpi_table_parse_entries() API to gracefully handle the acpi_disabled=1 case via return value rather than checking the global flag themselves. Signed-off-by: Feng Tang <feng.tang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-04-05Merge branch 'linus' into releaseLen Brown1-6/+14
Conflicts: arch/x86/kernel/cpu/cpufreq/longhaul.c Signed-off-by: Len Brown <len.brown@intel.com>
2009-04-03x86, ACPI: add support for x2apic ACPI extensionsSuresh Siddha1-0/+30
All logical processors with APIC ID values of 255 and greater will have their APIC reported through Processor X2APIC structure (type-9 entry type) and all logical processors with APIC ID less than 255 will have their APIC reported through legacy Processor Local APIC (type-0 entry type) only. This is the same case even for NMI structure reporting. The Processor X2APIC Affinity structure provides the association between the X2APIC ID of a logical processor and the proximity domain to which the logical processor belongs. For OSPM, Procssor IDs outside the 0-254 range are to be declared as Device() objects in the ACPI namespace. Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-02-09acpi/x86: introduce __apci_map_table, v4Yinghai Lu1-6/+14
to prevent wrongly overwriting fixmap that still want to use. ACPI used to rely on low mappings being all linearly mapped and grew a habit: it never really unmapped certain kinds of tables after use. This can cause problems - for example the hypothetical case when some spurious access still references it. v2: remove prev_map and prev_size in __apci_map_table v3: let acpi_os_unmap_memory() call early_iounmap too, so remove extral calling to early_acpi_os_unmap_memory v4: fix typo in one acpi_get_table_with_size calling Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Acked-by: Len Brown <len.brown@intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-02-06ACPI: disable ACPI cleanly when bad RSDP foundLen Brown1-1/+6
When ACPI is disabled in the BIOS of this VIA C3 box, it invalidates the RSDP, which Linux notices: ACPI Error (tbxfroot-0218): A valid RSDP was not found [20080926] Bug Linux neglected to disable ACPI at that stage, and later scribbled on smp_found_config: ACPI: No APIC-table, disabling MPS But this box doesn't run well in legacy PIC mode, it needed IOAPIC mode to perform correctly: http://lkml.org/lkml/2009/2/5/39 So exit ACPI mode cleanly when we first detect that it is hopeless. Signed-off-by: Len Brown <len.brown@intel.com>
2008-08-21acpi: add checking for NULL early paramCyrill Gorcunov1-0/+2
The early_param handling function could recieve NULL pointer as argument in case if user didn't enter parameter value. So we have to be ready for a such situation and do check for NULL pointer if needed. Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> Cc: Andi Kleen <andi@firstfloor.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Andi Kleen <ak@linux.intel.com>
2007-03-30Revert "ACPI: parse 2nd MADT by default"Len Brown1-1/+1
This reverts commit 09fe58356d148ff66901ddf639e725ca1a48a0af. http://bugzilla.kernel.org/show_bug.cgi?id=8283 Signed-off-by: Len Brown <len.brown@intel.com>
2007-03-15ACPI: parse 2nd MADT by defaultLen Brown1-1/+1
http://bugzilla.kernel.org/show_bug.cgi?id=7465 Signed-off-by: Len Brown <len.brown@intel.com>
2007-03-11ACPI: Add support to parse 2nd MADTLen Brown1-5/+52
When a BIOS bug presents multiple APIC/MADTs, Linux currently uses the 1st and ignores the 2nd. But some machines work better if we use the 2nd. http://bugzilla.kernel.org/show_bug.cgi?id=7465 Add a warning and boot parameter "acpi_apic_instance=2" to allow parsing the 2nd. No change to default behaviour in this patch. Signed-off-by: Len Brown <len.brown@intel.com>
2007-02-16Pull fluff into release branchLen Brown1-16/+25
Conflicts: arch/x86_64/pci/mmconfig.c drivers/acpi/bay.c Signed-off-by: Len Brown <len.brown@intel.com>
2007-02-14[PATCH] remove many unneeded #includes of sched.hTim Schmielau1-1/+0
After Al Viro (finally) succeeded in removing the sched.h #include in module.h recently, it makes sense again to remove other superfluous sched.h includes. There are quite a lot of files which include it but don't actually need anything defined in there. Presumably these includes were once needed for macros that used to live in sched.h, but moved to other header files in the course of cleaning it up. To ease the pain, this time I did not fiddle with any header files and only removed #includes from .c-files, which tend to cause less trouble. Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha, arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig, allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all configs in arch/arm/configs on arm. I also checked that no new warnings were introduced by the patch (actually, some warnings are removed that were emitted by unnecessarily included header files). Signed-off-by: Tim Schmielau <tim@physik3.uni-rostock.de> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-13ACPI: acpi_table_parse_madt_family() is not MADT specificLen Brown1-12/+12
acpi_table_parse_madt_family() is also used to parse SRAT entries. So re-name it to acpi_table_parse_entries(), and re-name the madt-specific variables within it accordingly. cosmetic only. Signed-off-by: Len Brown <len.brown@intel.com>
2007-02-13ACPI: acpi_madt_entry_handler() is not MADT specificLen Brown1-2/+2
acpi_madt_entry_handler() is also used for the SRAT, so re-name it acpi_table_entry_handler(). cosmetic only. Signed-off-by: Len Brown <len.brown@intel.com>
2007-02-13ACPI: acpi_table_parse() now returns success/fail, not countLen Brown1-2/+11
Returning count for tables that are supposed to be unique was useless and confusing. Signed-off-by: Len Brown <len.brown@intel.com>
2007-02-02ACPICA: Remove duplicate table definitions (non-conflicting)Alexey Starikovskiy1-54/+55
Signed-off-by: Len Brown <len.brown@intel.com>