26 Sep, 2020
1 commit
-
The ACPICA debug code is not used anywhere in processor_core.c
and processor_thermal.c, remove it.Signed-off-by: Hanjun Guo
[ rjw: Subject edit ]
Signed-off-by: Rafael J. Wysocki
21 May, 2019
1 commit
-
Add SPDX license identifiers to all files which:
- Have no license information of any form
- Have EXPORT_.*_SYMBOL_GPL inside which was used in the
initial scan/conversion to ignore the fileThese files fall under the project license, GPL v2 only. The resulting SPDX
license identifier is:GPL-2.0-only
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
21 Aug, 2018
1 commit
-
This is unnecessary and triggers a warning in the hypervisor.
Often systems have more processor entries in their ACPI tables than are
actually installed/active. The ACPI_STA_DEVICE_PRESENT bit cannot be
reliably used, but the ACPI_MADT_ENABLED bit can. In order to not
introduce new functions in the main ACPI processor driver code, simply
use acpi_get_phys_id(), which does more than we need, but which checks
the MADT enabled bit in the process. Any CPU for which we can't
determine the APIC ID is unlikely to work properly anyway, so the extra
checks done by acpi_get_phys_id() should do no harm.Signed-off-by: Jan Beulich
Reviewed-by: Juergen Gross
Acked-by: Rafael J. Wysocki
Signed-off-by: Boris Ostrovsky
11 Mar, 2017
2 commits
-
Revert: 8ad893faf2ea ("x86/acpi: Enable MADT APIs to return disabled apicids")
Remove the leftovers of the boot time 'cpuid nodeid' mapping approach.
Signed-off-by: Dou Liyang
Tested-by: Xiaolong Ye
Cc: rjw@rjwysocki.net
Cc: linux-acpi@vger.kernel.org
Cc: guzheng1@huawei.com
Cc: izumi.taku@jp.fujitsu.com
Cc: lenb@kernel.org
Link: http://lkml.kernel.org/r/1488528147-2279-3-git-send-email-douly.fnst@cn.fujitsu.com
Signed-off-by: Thomas Gleixner -
Revert: dc6db24d2476 ("x86/acpi: Set persistent cpuid nodeid mapping when booting")
The mapping of "cpuid nodeid" is established at boot time via ACPI
tables to keep associations of workqueues and other node related items
consistent across cpu hotplug.But, ACPI tables are unreliable and failures with that boot time mapping
have been reported on machines where the ACPI table and the physical
information which is retrieved at actual hotplug is inconsistent.Revert the mapping implementation so it can be replaced with a less error
prone approach.Signed-off-by: Dou Liyang
Tested-by: Xiaolong Ye
Cc: rjw@rjwysocki.net
Cc: linux-acpi@vger.kernel.org
Cc: guzheng1@huawei.com
Cc: izumi.taku@jp.fujitsu.com
Cc: lenb@kernel.org
Link: http://lkml.kernel.org/r/1488528147-2279-2-git-send-email-douly.fnst@cn.fujitsu.com
Signed-off-by: Thomas Gleixner
21 Dec, 2016
1 commit
-
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
Signed-off-by: Lv Zheng
Signed-off-by: Rafael J. Wysocki
24 Sep, 2016
1 commit
-
map_processor() checks the cpuid value returned by acpi_map_cpuid() for -1
but acpi_map_cpuid() returns -EINVAL in case of error.As a consequence the error is ignored and the following access into percpu
data with that negative cpuid results in a boot crash.This happens always when NR_CPUS/nr_cpu_ids is smaller than the number of
processors listed in the ACPI tables.Use a proper error check for id < 0 so the function returns instead of
trying to map CPU#(-EINVAL).Reported-by: Ingo Molnar
Signed-off-by: Thomas Gleixner
Cc: Dou Liyang
Cc: Gu Zheng
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Tang Chen
Cc: Zhu Guihua
Cc: akpm@linux-foundation.org
Cc: chen.tang@easystack.cn
Cc: cl@linux.com
Cc: gongzhaogang@inspur.com
Cc: isimatu.yasuaki@jp.fujitsu.com
Cc: izumi.taku@jp.fujitsu.com
Cc: kamezawa.hiroyu@jp.fujitsu.com
Cc: len.brown@intel.com
Cc: lenb@kernel.org
Cc: linux-acpi@vger.kernel.org
Cc: linux-mm@kvack.org
Cc: mika.j.penttila@gmail.com
Cc: rafael@kernel.org
Cc: rjw@rjwysocki.net
Cc: tj@kernel.org
Cc: yasu.isimatu@gmail.com
Fixes: dc6db24d2476 ("x86/acpi: Set persistent cpuid nodeid mapping when booting")
Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1609231705570.5640@nanos
Signed-off-by: Ingo Molnar
22 Sep, 2016
3 commits
-
When we want to identify whether the proc_id is unreasonable or not, we
can call the "acpi_processor_validate_proc_id" function. It will search
in the duplicate IDs. If we find the proc_id in the IDs, we return true
to the call function. Conversely, the false represents available.When we establish all possible cpuid nodeid mapping to handle the
cpu hotplugs, we will use the proc_id from ACPI table.We do validation when we get the proc_id. If the result is true, we
will stop the mapping.[ tglx: Mark the new function __init ]
Signed-off-by: Dou Liyang
Acked-by: Ingo Molnar
Cc: mika.j.penttila@gmail.com
Cc: len.brown@intel.com
Cc: rafael@kernel.org
Cc: rjw@rjwysocki.net
Cc: yasu.isimatu@gmail.com
Cc: linux-mm@kvack.org
Cc: linux-acpi@vger.kernel.org
Cc: isimatu.yasuaki@jp.fujitsu.com
Cc: gongzhaogang@inspur.com
Cc: tj@kernel.org
Cc: izumi.taku@jp.fujitsu.com
Cc: cl@linux.com
Cc: chen.tang@easystack.cn
Cc: akpm@linux-foundation.org
Cc: kamezawa.hiroyu@jp.fujitsu.com
Cc: lenb@kernel.org
Link: http://lkml.kernel.org/r/1472114120-3281-8-git-send-email-douly.fnst@cn.fujitsu.com
Signed-off-by: Thomas Gleixner -
The whole patch-set aims at making cpuid nodeid mapping persistent. So that,
when node online/offline happens, cache based on cpuid nodeid mapping such as
wq_numa_possible_cpumask will not cause any problem.
It contains 4 steps:
1. Enable apic registeration flow to handle both enabled and disabled cpus.
2. Introduce a new array storing all possible cpuid apicid mapping.
3. Enable _MAT and MADT relative apis to return non-present or disabled cpus' apicid.
4. Establish all possible cpuid nodeid mapping.This patch finishes step 4.
This patch set the persistent cpuid nodeid mapping for all enabled/disabled
processors at boot time via an additional acpi namespace walk for processors.[ tglx: Remove the unneeded exports ]
Signed-off-by: Gu Zheng
Signed-off-by: Tang Chen
Signed-off-by: Zhu Guihua
Signed-off-by: Dou Liyang
Acked-by: Ingo Molnar
Cc: mika.j.penttila@gmail.com
Cc: len.brown@intel.com
Cc: rafael@kernel.org
Cc: rjw@rjwysocki.net
Cc: yasu.isimatu@gmail.com
Cc: linux-mm@kvack.org
Cc: linux-acpi@vger.kernel.org
Cc: isimatu.yasuaki@jp.fujitsu.com
Cc: gongzhaogang@inspur.com
Cc: tj@kernel.org
Cc: izumi.taku@jp.fujitsu.com
Cc: cl@linux.com
Cc: chen.tang@easystack.cn
Cc: akpm@linux-foundation.org
Cc: kamezawa.hiroyu@jp.fujitsu.com
Cc: lenb@kernel.org
Link: http://lkml.kernel.org/r/1472114120-3281-6-git-send-email-douly.fnst@cn.fujitsu.com
Signed-off-by: Thomas Gleixner -
The whole patch-set aims at making cpuid nodeid mapping persistent. So that,
when node online/offline happens, cache based on cpuid nodeid mapping such as
wq_numa_possible_cpumask will not cause any problem.
It contains 4 steps:
1. Enable apic registeration flow to handle both enabled and disabled cpus.
2. Introduce a new array storing all possible cpuid apicid mapping.
3. Enable _MAT and MADT relative apis to return non-present or disabled cpus' apicid.
4. Establish all possible cpuid nodeid mapping.This patch finishes step 3.
There are four mappings in the kernel:
1. nodeid (logical node id) pxm (persistent)
2. apicid (physical cpu id) nodeid (persistent)
3. cpuid (logical cpu id) apicid (not persistent, now persistent by step 2)
4. cpuid (logical cpu id) nodeid (not persistent)So, in order to setup persistent cpuid nodeid mapping for all possible CPUs,
we should:
1. Setup cpuid apicid mapping for all possible CPUs, which has been done in step 1, 2.
2. Setup cpuid nodeid mapping for all possible CPUs. But before that, we should
obtain all apicids from MADT.All processors' apicids can be obtained by _MAT method or from MADT in ACPI.
The current code ignores disabled processors and returns -ENODEV.After this patch, a new parameter will be added to MADT APIs so that caller
is able to control if disabled processors are ignored.Signed-off-by: Gu Zheng
Signed-off-by: Tang Chen
Signed-off-by: Zhu Guihua
Signed-off-by: Dou Liyang
Acked-by: Ingo Molnar
Cc: mika.j.penttila@gmail.com
Cc: len.brown@intel.com
Cc: rafael@kernel.org
Cc: rjw@rjwysocki.net
Cc: yasu.isimatu@gmail.com
Cc: linux-mm@kvack.org
Cc: linux-acpi@vger.kernel.org
Cc: isimatu.yasuaki@jp.fujitsu.com
Cc: gongzhaogang@inspur.com
Cc: tj@kernel.org
Cc: izumi.taku@jp.fujitsu.com
Cc: cl@linux.com
Cc: chen.tang@easystack.cn
Cc: akpm@linux-foundation.org
Cc: kamezawa.hiroyu@jp.fujitsu.com
Cc: lenb@kernel.org
Link: http://lkml.kernel.org/r/1472114120-3281-5-git-send-email-douly.fnst@cn.fujitsu.com
Signed-off-by: Thomas Gleixner
30 May, 2016
1 commit
-
Follow-on arm64 ACPI/NUMA patches need to map MADT entries very early
(before kmalloc is usable).Add acpi_map_madt_entry() which, indirectly, uses
early_memremap()/early_memunmap() to access the table and parse out
the mpidr. The existing implementation of map_madt_entry() is
modified to take a pointer to the MADT as a parameter and the callers
adjusted.Signed-off-by: David Daney
Acked-by: Catalin Marinas
Signed-off-by: Rafael J. Wysocki
14 May, 2015
2 commits
-
Introduce invalid_phys_cpuid() to identify cpu with invalid
physical ID, then used it as replacement of the direct comparisons
with PHYS_CPUID_INVALID.Signed-off-by: Hanjun Guo
Signed-off-by: Rafael J. Wysocki -
Since invalid_logical_cpuid() can check error values, so
return specific error instead of -1 for acpi_map_cpuid().Signed-off-by: Hanjun Guo
Signed-off-by: Rafael J. Wysocki
26 Mar, 2015
2 commits
-
Introduce a new function map_gicc_mpidr() to allow MPIDRs to be obtained
from the GICC Structure introduced by ACPI 5.1, since MPIDR for ARM64 is
64-bit, so typedef u64 for phys_cpuid_t.The ARM architecture defines the MPIDR register as the CPU hardware
identifier. This patch adds the code infrastructure to retrieve the MPIDR
values from the ARM ACPI GICC structure in order to look-up the kernel CPU
hardware ids required by the ACPI core code to identify CPUs.CC: Rafael J. Wysocki
CC: Catalin Marinas
CC: Will Deacon
Tested-by: Suravee Suthikulpanit
Tested-by: Yijing Wang
Tested-by: Mark Langsdorf
Tested-by: Jon Masters
Tested-by: Timur Tabi
Tested-by: Robert Richter
Acked-by: Robert Richter
Acked-by: Lorenzo Pieralisi
Acked-by: Rafael J. Wysocki
Reviewed-by: Grant Likely
Signed-off-by: Hanjun Guo
Signed-off-by: Will Deacon -
CPU hardware ID (phys_id) is defined as u32 in structure acpi_processor,
but phys_id is used as int in acpi processor driver, so it will lead to
some inconsistence for the drivers.Furthermore, to cater for ACPI arch ports that implement 64 bits CPU
ids a generic CPU physical id type is required.So introduce typedef u32 phys_cpuid_t in a common file, and introduce
a macro PHYS_CPUID_INVALID as (phys_cpuid_t)(-1) if it's not defined
by other archs, this will solve the inconsistence in acpi processor driver,
and will prepare for the ACPI on ARM64 for the 64 bit CPU hardware ID
in the following patch.CC: Rafael J Wysocki
Suggested-by: Lorenzo Pieralisi
Reviewed-by: Grant Likely
Acked-by: Sudeep Holla
Acked-by: Lorenzo Pieralisi
Acked-by: Rafael J. Wysocki
Signed-off-by: Catalin Marinas
[hj: reworked cpu physid map return codes]
Signed-off-by: Hanjun Guo
Signed-off-by: Will Deacon
05 Feb, 2015
1 commit
-
We need to parse APIC ID for IOAPIC registration for IOAPIC hotplug.
ACPI _MAT method and MADT table are used to figure out IOAPIC ID, just
like parsing CPU APIC ID for CPU hotplug.[ tglx: Fixed docbook comment ]
Signed-off-by: Yinghai Lu
Signed-off-by: Jiang Liu
Cc: Konrad Rzeszutek Wilk
Cc: Tony Luck
Cc: Joerg Roedel
Cc: Greg Kroah-Hartman
Cc: Benjamin Herrenschmidt
Cc: Rafael J. Wysocki
Cc: Bjorn Helgaas
Cc: Randy Dunlap
Cc: Borislav Petkov
Cc: Len Brown
Link: http://lkml.kernel.org/r/1414387308-27148-8-git-send-email-jiang.liu@linux.intel.com
Signed-off-by: Thomas Gleixner
Signed-off-by: Rafael J. Wysocki
06 Jan, 2015
1 commit
-
apic_id in MADT table is the CPU hardware id which identify
it self in the system for x86 and ia64, OSPM will use it for
SMP init to map APIC ID to logical cpu number in the early
boot, when the DSDT/SSDT (ACPI namespace) is scanned later, the
ACPI processor driver is probed and the driver will use acpi_id
in DSDT to get the apic_id, then map to the logical cpu number
which is needed by the processor driver.Before ACPI 5.0, only x86 and ia64 were supported in ACPI spec,
so apic_id is used both in arch code and ACPI core which is
pretty fine. Since ACPI 5.0, ARM is supported by ACPI and
APIC is not available on ARM, this will confuse people when
apic_id is both used by x86 and ARM in one function.So convert apic_id to phys_id (which is the original meaning)
in ACPI processor dirver to make it arch agnostic, but leave the
arch dependent code unchanged, no functional change.Signed-off-by: Hanjun Guo
Signed-off-by: Rafael J. Wysocki
16 Dec, 2014
1 commit
-
Fix minor syntax issues in processor_core.c to follow coding styles.
Signed-off-by: Jiang Liu
Cc: Konrad Rzeszutek Wilk
Cc: Tony Luck
Cc: Joerg Roedel
Cc: Greg Kroah-Hartman
Cc: Benjamin Herrenschmidt
Cc: Rafael J. Wysocki
Cc: Bjorn Helgaas
Cc: Randy Dunlap
Cc: Yinghai Lu
Cc: Borislav Petkov
Cc: Len Brown
Link: http://lkml.kernel.org/r/1414387308-27148-7-git-send-email-jiang.liu@linux.intel.com
Signed-off-by: Thomas Gleixner
25 Sep, 2014
1 commit
-
Use container_of instead of casting first structure member to resolve
acpi_madt_local_apic/sapic/x2apic from acpi_subtable_header.Signed-off-by: Fabian Frederick
[ rjw: Subject and changelog ]
Signed-off-by: Rafael J. Wysocki
06 Aug, 2014
1 commit
-
* acpi-video:
ACPI / video: Add use_native_backlight quirk for HP EliteBook 2014 models* acpi-battery:
ACPI / battery: remove duplicated include from battery.c* acpi-processor:
ACPI / processor: Make it possible to get local x2apic id via _MAT* acpi-lpss:
ACPI / LPSS: add LPSS device for Wildcat Point PCH
30 Jul, 2014
1 commit
-
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
Signed-off-by: Rafael J. Wysocki
21 Jul, 2014
1 commit
-
The use of _PDC is deprecated in ACPI 3.0 in favor of _OSC,
as ARM platform is supported only in ACPI 5.0 or higher version,
_PDC will not be used in ARM platform, so make Make _PDC only for
platforms with Intel CPUs.Introduce ARCH_MIGHT_HAVE_ACPI_PDC and move _PDC related code in
ACPI processor driver into a single file processor_pdc.c, make x86
and ia64 select it when ACPI is enabled.This patch also use pr_* to replace printk to fix the checkpatch
warning and factor acpi_processor_alloc_pdc() a little bit to
avoid duplicate pr_err() code.Suggested-by: Robert Richter
Signed-off-by: Hanjun Guo
Signed-off-by: Rafael J. Wysocki
02 Apr, 2014
1 commit
-
* acpi-processor:
Revert "ACPI / processor: Make it possible to get APIC ID via GIC"* pnp:
PNP: remove deprecated IRQF_DISABLED
26 Mar, 2014
1 commit
-
Revert commit df86f5df79d8 (ACPI / processor: Make it possible to get
APIC ID via GIC).APIC ID refers the hardware ID of the CPU, which means MPIDR on
ARM/ARM64, but in ACPI 5.0, GIC ID feild in GIC structure have
no explicit definition and may not refer to the MPIDR.Commit df86f5df79d8 assumed that gic->gic_id as MPIDR which may not be
the case, so revert it until the explicit definition of GIC structure
is ready.Signed-off-by: Hanjun Guo
[rjw: Changelog]
Signed-off-by: Rafael J. Wysocki
21 Mar, 2014
1 commit
-
* acpi-processor:
ACPI: Move BAD_MADT_ENTRY() to linux/acpi.h
ACPI / processor: Make it possible to get APIC ID via GIC
ACPI / processor: Build idle_boot_override on x86 and ia64
ACPI / processor: Use ACPI_PROCESSOR_DEVICE_HID instead of "ACPI0007"
ACPI / processor: Fix acpi_processor_eval_pdc() return value type
19 Mar, 2014
1 commit
-
We already have a macro for PREFIX of "ACPI: " in
drivers/acpi/internal.h, so remove the duplicate ones
in ACPI drivers when internal.h is included.Signed-off-by: Hanjun Guo
Signed-off-by: Rafael J. Wysocki
19 Feb, 2014
4 commits
-
Introduce a new function map_gic_id() to allow APIC IDs to be obtained
from the GIC Structure introduced by ACPI 5.Signed-off-by: Hanjun Guo
[rjw: Subject and changelog]
Signed-off-by: Rafael J. Wysocki -
idle_boot_override depends on x86 and ia64 now and it is not clear
whether or not it will be used on ARM or ARM64, so put the DMI
blacklist setting it in processor_core.c into a #if block so that
it is built for CONFIG_X86 or CONFIG_IA64 only to allow
processor_core.c to be compiled for ARM64.Signed-off-by: Hanjun Guo
[rjw: Subject and changelog]
Signed-off-by: Rafael J. Wysocki -
Replace "ACPI0007" with ACPI_PROCESSOR_DEVICE_HID to improve code
readability.Signed-off-by: Hanjun Guo
Signed-off-by: Rafael J. Wysocki -
The return value type of acpi_processor_eval_pdc() should be
'acpi_status' but is defined as 'int', so fix it.Signed-off-by: Hanjun Guo
Signed-off-by: Rafael J. Wysocki
29 Jan, 2014
1 commit
-
* acpi-processor:
ACPI / scan: reduce log level of "ACPI: \_PR_.CPU4: failed to get CPU APIC ID"
ACPI / processor: Return specific error value when mapping lapic id* acpi-hotplug:
ACPI / scan: Clear match_driver flag in acpi_bus_trim()* acpi-init:
ACPI / init: Flag use of ACPI and ACPI idioms for power supplies to regulator API* acpi-pm:
ACPI / PM: Use ACPI_COMPANION() to get ACPI companions of devices* acpica:
ACPICA: Remove bool usage from ACPICA.
28 Jan, 2014
1 commit
-
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
07 Dec, 2013
1 commit
-
Replace direct inclusions of , and
, which are incorrect, with
inclusions and remove some inclusions of those files that aren't
necessary.First of all, , and
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,
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 be included
prior to so that the acpi_pci_root declarations the
latter depends on are always there. And 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
as appropriate.Signed-off-by: Lv Zheng
Cc: Greg Kroah-Hartman
Cc: Matthew Garrett
Cc: Tony Luck
Cc: "H. Peter Anvin"
Acked-by: Bjorn Helgaas (drivers/pci stuff)
Acked-by: Konrad Rzeszutek Wilk (Xen stuff)
Signed-off-by: Rafael J. Wysocki
24 Sep, 2013
1 commit
-
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
Signed-off-by: Hanjun Guo
Signed-off-by: Rafael J. Wysocki
15 Aug, 2013
1 commit
08 Aug, 2013
1 commit
-
__initdata should be placed between the variable name and equal
sign for the variable to be placed in the intended section.Signed-off-by: Sachin Kamat
Signed-off-by: Rafael J. Wysocki
15 Jul, 2013
1 commit
-
The __cpuinit type of throwaway sections might have made sense
some time ago when RAM was more constrained, but now the savings
do not offset the cost and complications. For example, the fix in
commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time")
is a good example of the nasty type of bugs that can be created
with improper use of the various __init prefixes.After a discussion on LKML[1] it was decided that cpuinit should go
the way of devinit and be phased out. Once all the users are gone,
we can then finally remove the macros themselves from linux/init.h.This removes all the drivers/acpi uses of the __cpuinit macros
from all C files.[1] https://lkml.org/lkml/2013/5/20/589
Cc: Len Brown
Cc: "Rafael J. Wysocki"
Cc: linux-acpi@vger.kernel.org
Signed-off-by: Paul Gortmaker
04 Mar, 2013
1 commit
-
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
Signed-off-by: Rafael J. Wysocki
13 Jul, 2012
1 commit
-
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 bladeThis patch restricts the introduced workaround to platforms
with nr_cpu_ids
CC: stable@vger.kernel.org
Signed-off-by: Rafael J. Wysocki
17 Jan, 2012
1 commit
-
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 exampleScope (_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
Signed-off-by: Len Brown
