linux-toradex.git/drivers/acpi/acpi_processor.c, branch v4.19-rc1

ACPI: Mark expected switch fall-throughs

2017-11-08T23:55:16+00:00

In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.

Signed-off-by: Gustavo A. R. Silva 
Signed-off-by: Rafael J. Wysocki

ACPI / processor: make function acpi_processor_check_duplicates() static

2017-08-24T01:25:47+00:00

The function acpi_processor_check_duplicates() is local to the source
and does not need to be in global scope, so make it static.

Cleans up sparse warnings:
symbol 'acpi_processor_check_duplicates' was not declared. Should it
be static?

Signed-off-by: Colin Ian King 
Signed-off-by: Rafael J. Wysocki

ACPI / Processor: Drop setup_max_cpus check from acpi_processor_add()

2017-04-18T14:50:24+00:00

When maxcpus=X kernel argument is used, we parse the ACPI tables only
for the first X cpus. The per-cpu ACPI data include the _PSD tables
which gives information about related cpus.

cppc_cpufreq and acpi-cpufreq parses the table once during init to
deduce the related cpus. If a user brings a new cpu online after boot
the related cpu data becomes incorrect.

acpi_get_psd_map() in acpi_cppc.c returns error if it fails to find
the parsed ACPI data for possible CPU resulting in cppc_cpufreq
initialization failure.

With this change we will probe all possible CPUs prior to cpufreq
initialization, but will bring only setup_max_cpus online. nr_cpus
kernel parameter can be used to restict even parsing per-cpu ACPI
tables.

Signed-off-by: Prashanth Prakash 
[ rjw: Subject ]
Signed-off-by: Rafael J. Wysocki

acpi/processor: Check for duplicate processor ids at hotplug time

2017-03-11T13:41:20+00:00

The check for duplicate processor ids happens at boot time based on the
ACPI table contents, but the final sanity checks for a processor happen
at hotplug time.

At hotplug time, where the physical information is available, which might
differ from the ACPI table information, a check for duplicate processor
ids is missing.

Add it to the hotplug checks and rename the function so it better
reflects its purpose.

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-6-git-send-email-douly.fnst@cn.fujitsu.com
Signed-off-by: Thomas Gleixner

acpi/processor: Implement DEVICE operator for processor enumeration

2017-03-11T13:41:20+00:00

ACPI allows to declare processors either with the PROCESSOR or with the
DEVICE operator. The current implementation handles only the PROCESSOR
operator.

On a system which uses the DEVICE operator for processor enumeration the
evaluation fails.

Check for the ACPI type of the ACPI handle and evaluate PROCESSOR and
DEVICE types separately.

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-5-git-send-email-douly.fnst@cn.fujitsu.com
Signed-off-by: Thomas Gleixner

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

2017-03-11T13:41:18+00:00

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

x86/ACPI: keep x86_cpu_to_acpiid mapping valid on CPU hotplug

2017-02-07T12:34:56+00:00

We may or may not have all possible CPUs in MADT on boot but in any
case we're overwriting x86_cpu_to_acpiid mapping with U32_MAX when
acpi_register_lapic() is called again on the CPU hotplug path:

acpi_processor_hotadd_init()
  -> acpi_map_cpu()
    -> acpi_register_lapic()

As we have the required acpi_id information in acpi_processor_hotadd_init()
propagate it to acpi_map_cpu() to always keep x86_cpu_to_acpiid
mapping valid.

Reported-by: Andrew Jones 
Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: Rafael J. Wysocki

acpi: Validate processor id when mapping the processor

2016-09-21T19:18:40+00:00

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

acpi: Provide mechanism to validate processors in the ACPI tables

2016-09-21T19:18:39+00:00

[Problem]

When we set cpuid <-> nodeid mapping to be persistent, it will use the DSDT
As we know, the ACPI tables are just like user's input in that respect, and
we don't crash if user's input is unreasonable.

Such as, the mapping of the proc_id and pxm in some machine's ACPI table is
like this:

proc_id   |    pxm
--------------------
0       <->     0
1       <->     0
2       <->     1
3       <->     1
89      <->     0
89      <->     0
89      <->     0
89      <->     1
89      <->     1
89      <->     2
89      <->     3
.....

We can't be sure which one is correct to the proc_id 89. We may map a wrong
node to a cpu. When pages are allocated, this may cause a kernal panic.

So, we should provide mechanisms to validate the ACPI tables, just like we
do validation to check user's input in web project.

The mechanism is that the processor objects which have the duplicate IDs
are not valid.

[Solution]

We add a validation function, like this:

foreach Processor in DSDT
	proc_id = get_ACPI_Processor_number(Processor)
	if (proc_id exists )
		mark both of them as being unreasonable;

The function will record the unique or duplicate processor IDs.

The duplicate processor IDs such as 89 are regarded as the unreasonable IDs
which mean that the processor objects in question are not valid.

[ tglx: Add __init[data] annotations ]

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-7-git-send-email-douly.fnst@cn.fujitsu.com
Signed-off-by: Thomas Gleixner

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

2016-09-21T19:18:39+00:00

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