irqchip/gic-v3: Add support for ACPI's disabled but 'online capable' CPUs

To support virtual CPU hotplug, ACPI has added an 'online capable' bit
to the MADT GICC entries. This indicates a disabled C

irqchip/gic-v3: Add support for ACPI's disabled but 'online capable' CPUs

To support virtual CPU hotplug, ACPI has added an 'online capable' bit
to the MADT GICC entries. This indicates a disabled CPU entry may not
be possible to online via PSCI until firmware has set enabled bit in
_STA.

This means that a "usable" GIC redistributor is one that is marked as
either enabled, or online capable. The meaning of the
acpi_gicc_is_usable() would become less clear than just checking the
pair of flags at call sites. As such, drop that helper function.
The test in gic_acpi_match_gicc() remains as testing just the
enabled bit so the count of enabled distributors is correct.

What about the redistributor in the GICC entry? ACPI doesn't want to say.
Assume the worst: When a redistributor is described in the GICC entry,
but the entry is marked as disabled at boot, assume the redistributor
is inaccessible.

The GICv3 driver doesn't support late online of redistributors, so this
means the corresponding CPU can't be brought online either.
Rather than modifying cpu masks that may already have been used,
register a new cpuhp callback to fail this case. This must run earlier
than the main gic_starting_cpu() so that this case can be rejected
before the section of cpuhp that runs on the CPU that is coming up as
that is not allowed to fail. This solution keeps the handling of this
broken firmware corner case local to the GIC driver. As precise ordering
of this callback doesn't need to be controlled as long as it is
in that initial prepare phase, use CPUHP_BP_PREPARE_DYN.

Systems that want CPU hotplug in a VM can ensure their redistributors
are always-on, and describe them that way with a GICR entry in the MADT.

Suggested-by: Marc Zyngier <[email protected]>
Signed-off-by: James Morse <[email protected]>
Signed-off-by: Russell King (Oracle) <[email protected]>
Tested-by: Miguel Luis <[email protected]>
Co-developed-by: Jonathan Cameron <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>
Acked-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Catalin Marinas <[email protected]>

show more ...

irqchip/gic-v3: Enable non-coherent redistributors/ITSes ACPI probing

The GIC architecture specification defines a set of registers for
redistributors and ITSes that control the sharebility and cach

irqchip/gic-v3: Enable non-coherent redistributors/ITSes ACPI probing

The GIC architecture specification defines a set of registers for
redistributors and ITSes that control the sharebility and cacheability
attributes of redistributors/ITSes initiator ports on the interconnect
(GICR_[V]PROPBASER, GICR_[V]PENDBASER, GITS_BASER<n>).

Architecturally the GIC provides a means to drive shareability and
cacheability attributes signals but it is not mandatory for designs to
wire up the corresponding interconnect signals that control the
cacheability/shareability of transactions.

Redistributors and ITSes interconnect ports can be connected to
non-coherent interconnects that are not able to manage the
shareability/cacheability attributes; this implicitly makes the
redistributors and ITSes non-coherent observers.

To enable non-coherent GIC designs on ACPI based systems, parse the MADT
GICC/GICR/ITS subtables non-coherent flags to determine whether the
respective components are non-coherent observers and force the
shareability attributes to be programmed into the redistributors and
ITSes registers.

An ACPI global function (acpi_get_madt_revision()) is added to retrieve
the MADT revision, in that it is essential to check the MADT revision
before checking for flags that were added with MADT revision 7 so that
if the kernel is booted with an ACPI MADT table with revision < 7 it
skips parsing the newly added flags (that should be zeroed reserved
values for MADT versions < 7 but they could turn out to be buggy and
should be ignored).

Signed-off-by: Lorenzo Pieralisi <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Reviewed-by: Robin Murphy <[email protected]>
Acked-by: Marc Zyngier <[email protected]>
Cc: "Rafael J. Wysocki" <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

arm64, irqchip/gic-v3, ACPI: Move MADT GICC enabled check into a helper

ACPI, irqchip and the architecture code all inspect the MADT
enabled bit for a GICC entry in the MADT.

The addition of an 'on

arm64, irqchip/gic-v3, ACPI: Move MADT GICC enabled check into a helper

ACPI, irqchip and the architecture code all inspect the MADT
enabled bit for a GICC entry in the MADT.

The addition of an 'online capable' bit means all these sites need
updating.

Move the current checks behind a helper to make future updates easier.

Signed-off-by: James Morse <[email protected]>
Reviewed-by: Jonathan Cameron <[email protected]>
Reviewed-by: Gavin Shan <[email protected]>
Signed-off-by: "Russell King (Oracle)" <[email protected]>
Acked-by: "Rafael J. Wysocki" <[email protected]>
Reviewed-by: Sudeep Holla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Catalin Marinas <[email protected]>

show more ...

ACPI: processor: LoongArch: Get physical ID from MADT

With ACPI Spec 6.5 chapter 5.2.12.20, each processor in LoongArch
systems has a Core Programmable Interrupt Controller in MADT. The
value of its

ACPI: processor: LoongArch: Get physical ID from MADT

With ACPI Spec 6.5 chapter 5.2.12.20, each processor in LoongArch
systems has a Core Programmable Interrupt Controller in MADT. The
value of its type is 0x11 in the spec and defined as enum variable
ACPI_MADT_TYPE_CORE_PIC in the Linux kernel.

Physical IDs can be retrieved from MADT for LoongArch systems during
initialization and they can be retrieved from the _MAT output for
hotplug CPUs.

Add physical CPU ID enumeration for LoongArch systems.

Signed-off-by: Bibo Mao <[email protected]>
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: processor_core: RISC-V: Enable mapping processor to the hartid

processor_core needs arch-specific functions to map the ACPI ID
to the physical ID. In RISC-V platforms, hartid is the physical i

ACPI: processor_core: RISC-V: Enable mapping processor to the hartid

processor_core needs arch-specific functions to map the ACPI ID
to the physical ID. In RISC-V platforms, hartid is the physical id
and RINTC structure in MADT provides this mapping. Add arch-specific
function to get this mapping from RINTC.

Signed-off-by: Sunil V L <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Reviewed-by: Andrew Jones <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Palmer Dabbelt <[email protected]>

show more ...

ACPI: processor: Remove dead ACPICA debug code

The ACPICA debug code is not used anywhere in processor_core.c
and processor_thermal.c, remove it.

Signed-off-by: Hanjun Guo <[email protected]>
[

ACPI: processor: Remove dead ACPICA debug code

The ACPICA debug code is not used anywhere in processor_core.c
and processor_thermal.c, remove it.

Signed-off-by: Hanjun Guo <[email protected]>
[ rjw: Subject edit ]
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

treewide: Add SPDX license identifier for missed files

Add SPDX license identifiers to all files which:

- Have no license information of any form

- Have EXPORT_.*_SYMBOL_GPL inside which was use

treewide: Add SPDX license identifier for missed files

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 file

These files fall under the project license, GPL v2 only. The resulting SPDX
license identifier is:

GPL-2.0-only

Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

xen/ACPI: don't upload Px/Cx data for disabled processors

This is unnecessary and triggers a warning in the hypervisor.

Often systems have more processor entries in their ACPI tables than are
actua

xen/ACPI: don't upload Px/Cx data for disabled processors

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 <[email protected]>
Reviewed-by: Juergen Gross <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Boris Ostrovsky <[email protected]>

show more ...

Revert"x86/acpi: Enable MADT APIs to return disabled apicids"

Revert: 8ad893faf2ea ("x86/acpi: Enable MADT APIs to return disabled apicids")

Remove the leftovers of the boot time 'cpuid <-> nodeid'

Revert"x86/acpi: Enable MADT APIs to return disabled apicids"

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 <[email protected]>
Tested-by: Xiaolong Ye <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>

show more ...

Revert "x86/acpi: Set persistent cpuid <-> nodeid mapping when booting"

Revert: dc6db24d2476 ("x86/acpi: Set persistent cpuid <-> nodeid mapping when booting")

The mapping of "cpuid <-> nodeid" is

Revert "x86/acpi: Set persistent cpuid <-> nodeid mapping when booting"

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 <[email protected]>
Tested-by: Xiaolong Ye <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>

show more ...

ACPI / osl: Remove acpi_get_table_with_size()/early_acpi_os_unmap_memory() users

This patch removes the users of the deprectated APIs:
acpi_get_table_with_size()
early_acpi_os_unmap_memory()
The f

ACPI / osl: Remove acpi_get_table_with_size()/early_acpi_os_unmap_memory() users

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 <[email protected]>
Signed-off-by: Lv Zheng <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

acpi: Fix broken error check in map_processor()

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 th

acpi: Fix broken error check in map_processor()

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 <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: Dou Liyang <[email protected]>
Cc: Gu Zheng <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Tang Chen <[email protected]>
Cc: Zhu Guihua <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
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 <[email protected]>

show more ...

acpi: Validate processor id when mapping the processor

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

acpi: Validate processor id when mapping the processor

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 <[email protected]>
Acked-by: Ingo Molnar <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>

show more ...

x86/acpi: Set persistent cpuid <-> nodeid mapping when booting

The whole patch-set aims at making cpuid <-> nodeid mapping persistent. So that,
when node online/offline happens, cache based on cpuid

x86/acpi: Set persistent cpuid <-> nodeid mapping when booting

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 <[email protected]>
Signed-off-by: Tang Chen <[email protected]>
Signed-off-by: Zhu Guihua <[email protected]>
Signed-off-by: Dou Liyang <[email protected]>
Acked-by: Ingo Molnar <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>

show more ...

x86/acpi: Enable MADT APIs to return disabled apicids

The whole patch-set aims at making cpuid <-> nodeid mapping persistent. So that,
when node online/offline happens, cache based on cpuid <-> node

x86/acpi: Enable MADT APIs to return disabled apicids

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 <[email protected]>
Signed-off-by: Tang Chen <[email protected]>
Signed-off-by: Zhu Guihua <[email protected]>
Signed-off-by: Dou Liyang <[email protected]>
Acked-by: Ingo Molnar <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>

show more ...

ACPI / processor: Add acpi_map_madt_entry()

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

ACPI / processor: Add acpi_map_madt_entry()

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 <[email protected]>
Acked-by: Catalin Marinas <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI / processor: Introduce invalid_phys_cpuid()

Introduce invalid_phys_cpuid() to identify cpu with invalid
physical ID, then used it as replacement of the direct comparisons
with PHYS_CPUID_INVALI

ACPI / processor: Introduce invalid_phys_cpuid()

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 <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI / processor: return specific error instead of -1

Since invalid_logical_cpuid() can check error values, so
return specific error instead of -1 for acpi_map_cpuid().

Signed-off-by: Hanjun Guo <h

ACPI / processor: return specific error instead of -1

Since invalid_logical_cpuid() can check error values, so
return specific error instead of -1 for acpi_map_cpuid().

Signed-off-by: Hanjun Guo <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI / processor: Make it possible to get CPU hardware ID via GICC

Introduce a new function map_gicc_mpidr() to allow MPIDRs to be obtained
from the GICC Structure introduced by ACPI 5.1, since MPID

ACPI / processor: Make it possible to get CPU hardware ID via GICC

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 <[email protected]>
CC: Catalin Marinas <[email protected]>
CC: Will Deacon <[email protected]>
Tested-by: Suravee Suthikulpanit <[email protected]>
Tested-by: Yijing Wang <[email protected]>
Tested-by: Mark Langsdorf <[email protected]>
Tested-by: Jon Masters <[email protected]>
Tested-by: Timur Tabi <[email protected]>
Tested-by: Robert Richter <[email protected]>
Acked-by: Robert Richter <[email protected]>
Acked-by: Lorenzo Pieralisi <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Reviewed-by: Grant Likely <[email protected]>
Signed-off-by: Hanjun Guo <[email protected]>
Signed-off-by: Will Deacon <[email protected]>

show more ...

ACPI / processor: Introduce phys_cpuid_t for CPU hardware ID

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

ACPI / processor: Introduce phys_cpuid_t for CPU hardware ID

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 <[email protected]>
Suggested-by: Lorenzo Pieralisi <[email protected]>
Reviewed-by: Grant Likely <[email protected]>
Acked-by: Sudeep Holla <[email protected]>
Acked-by: Lorenzo Pieralisi <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Catalin Marinas <[email protected]>
[hj: reworked cpu physid map return codes]
Signed-off-by: Hanjun Guo <[email protected]>
Signed-off-by: Will Deacon <[email protected]>

show more ...

ACPI: Add interfaces to parse IOAPIC ID for IOAPIC hotplug

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

ACPI: Add interfaces to parse IOAPIC ID for IOAPIC hotplug

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 <[email protected]>
Signed-off-by: Jiang Liu <[email protected]>
Cc: Konrad Rzeszutek Wilk <[email protected]>
Cc: Tony Luck <[email protected]>
Cc: Joerg Roedel <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Benjamin Herrenschmidt <[email protected]>
Cc: Rafael J. Wysocki <[email protected]>
Cc: Bjorn Helgaas <[email protected]>
Cc: Randy Dunlap <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Len Brown <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI / processor: Convert apic_id to phys_id to make it arch agnostic

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 ini

ACPI / processor: Convert apic_id to phys_id to make it arch agnostic

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 <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: Fix minor syntax issues in processor_core.c

Fix minor syntax issues in processor_core.c to follow coding styles.

Signed-off-by: Jiang Liu <[email protected]>
Cc: Konrad Rzeszutek Wilk

ACPI: Fix minor syntax issues in processor_core.c

Fix minor syntax issues in processor_core.c to follow coding styles.

Signed-off-by: Jiang Liu <[email protected]>
Cc: Konrad Rzeszutek Wilk <[email protected]>
Cc: Tony Luck <[email protected]>
Cc: Joerg Roedel <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Benjamin Herrenschmidt <[email protected]>
Cc: Rafael J. Wysocki <[email protected]>
Cc: Bjorn Helgaas <[email protected]>
Cc: Randy Dunlap <[email protected]>
Cc: Yinghai Lu <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Len Brown <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>

show more ...

ACPI / processor: use container_of instead of casting first structure member

Use container_of instead of casting first structure member to resolve
acpi_madt_local_apic/sapic/x2apic from acpi_subtabl

ACPI / processor: use container_of instead of casting first structure member

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 <[email protected]>
[ rjw: Subject and changelog ]
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

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
proces

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 <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...