linux/drivers/acpi/acpi_processor.c, branch v4.8

ACPI / processor: Avoid reserving IO regions too early

2016-06-01T23:57:50Z

Roland Dreier reports that one of his systems cannot boot because of the changes made by commit ac212b6980d8 (ACPI / processor: Use common hotplug infrastructure). The problematic part of it is the request_region() call in acpi_processor_get_info() that used to run at module init time before the above commit and now it runs much earlier. Unfortunately, the region(s) reserved by it fall into a range the PCI subsystem attempts to reserve for AHCI IO BARs. As a result, the PCI reservation fails and AHCI doesn't work, while previously the PCI reservation would be made before acpi_processor_get_info() and it would succeed. That request_region() call, however, was overlooked by commit ac212b6980d8, as it is not necessary for the enumeration of the processors. It only is needed when the ACPI processor driver actually attempts to handle them which doesn't happen before loading the ACPI processor driver module. Therefore that call should have been moved from acpi_processor_get_info() into that module. Address the problem by moving the request_region() call in question out of acpi_processor_get_info() and use the observation that the region reserved by it is only needed if the FADT-based CPU throttling method is going to be used, which means that it should be sufficient to invoke it from acpi_processor_get_throttling_fadt(). Fixes: ac212b6980d8 (ACPI / processor: Use common hotplug infrastructure) Reported-by: Roland Dreier Tested-by: Roland Dreier Signed-off-by: Rafael J. Wysocki

ACPI / processor: Request native thermal interrupt handling via _OSC

2016-03-26T01:00:38Z

There are several reports of freeze on enabling HWP (Hardware PStates) feature on Skylake-based systems by the Intel P-states driver. The root cause is identified as the HWP interrupts causing BIOS code to freeze. HWP interrupts use the thermal LVT which can be handled by Linux natively, but on the affected Skylake-based systems SMM will respond to it by default. This is a problem for several reasons: - On the affected systems the SMM thermal LVT handler is broken (it will crash when invoked) and a BIOS update is necessary to fix it. - With thermal interrupt handled in SMM we lose all of the reporting features of the arch/x86/kernel/cpu/mcheck/therm_throt driver. - Some thermal drivers like x86-package-temp depend on the thermal threshold interrupts signaled via the thermal LVT. - The HWP interrupts are useful for debugging and tuning performance (if the kernel can handle them). The native handling of thermal interrupts needs to be enabled because of that. This requires some way to tell SMM that the OS can handle thermal interrupts. That can be done by using _OSC/_PDC in processor scope very early during ACPI initialization. The meaning of _OSC/_PDC bit 12 in processor scope is whether or not the OS supports native handling of interrupts for Collaborative Processor Performance Control (CPPC) notifications. Since on HWP-capable systems CPPC is a firmware interface to HWP, setting this bit effectively tells the firmware that the OS will handle thermal interrupts natively going forward. For details on _OSC/_PDC refer to: http://www.intel.com/content/www/us/en/standards/processor-vendor-specific-acpi-specification.html To implement the _OSC/_PDC handshake as described, introduce a new function, acpi_early_processor_osc(), that walks the ACPI namespace looking for ACPI processor objects and invokes _OSC for them with bit 12 in the capabilities buffer set and terminates the namespace walk on the first success. Also modify intel_thermal_interrupt() to clear HWP status bits in the HWP_STATUS MSR to acknowledge HWP interrupts (which prevents them from firing continuously). Signed-off-by: Srinivas Pandruvada [ rjw: Subject & changelog, function rename ] Signed-off-by: Rafael J. Wysocki

ACPI / processor : add support for ACPI0010 processor container

2016-02-21T23:53:56Z

ACPI 6.0 adds support for optional processor container device which may contain child objects that are either processor devices or other processor containers. This allows representing hierarchical processor topologies. It is declared using the _HID of ACPI0010. It is an abstract container used to represent CPU topology and should not be used to hotplug purposes. If no matching handler is found for a device in acpi_scan_attach_handler, acpi_bus_attach does a default enumeration for those devices with valid HID in the acpi namespace. This patch adds a scan handler for these ACPI processor containers to avoid default that enumeration and ensures the platform devices are not created for them. Signed-off-by: Sudeep Holla Signed-off-by: Rafael J. Wysocki

ACPI: Add weak routines for ACPI CPU Hotplug

2015-10-12T21:08:03Z

Add weak functions for architectures which do not support hot-adding and removing CPUs which aren't detected at bootup. (e.g. via MADT). This helps preserve the Kconfig dependency from: commit cbfc1bae55bb ("[ACPI] ACPI_HOTPLUG_CPU Kconfig dependency update") prevent: HOTPLUG_CPU=y ACPI_PROCESSOR=y ACPI_HOTPLUG_CPU=n Signed-off-by: Ashwin Chaugule Signed-off-by: Rafael J. Wysocki

ACPI / processor: remove leftover __refdata annotations

2015-07-20T23:01:46Z

The processor_handler structure does not reference any __init / __exit code or data. Therefore the __refdata annotation is not needed. It used to be prior to commit fe7bf106ebc2 ("acpi: delete __cpuinit usage from all acpi files") due to the __cpuinit annotation of acpi_processor_add(). But with that commit in place that requirement has gone. The same is true for the acpi_cpu_notifier notifier block. acpi_cpu_soft_notify() used to be marked __cpuinit but lost its annotation in the above mentioned commit as well. Therefore the __refdata annotation isn't needed there either. Just drop the unneded __refdata annotations to be able to catch future section mismatches. Signed-off-by: Mathias Krause Signed-off-by: Rafael J. Wysocki

ACPI / processor: Introduce invalid_phys_cpuid()

2015-05-13T21:28:16Z

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

ACPI / processor: remove phys_id in acpi_processor_get_info()

2015-05-13T21:28:15Z

Use pr->phys_id to replace phys_id to simplify the code. Signed-off-by: Hanjun Guo Signed-off-by: Rafael J. Wysocki

ACPI / processor: remove cpu_index in acpi_processor_get_info()

2015-05-13T21:28:15Z

Just use pr->id instead of cpu_index to simplify the code. Signed-off-by: Hanjun Guo Signed-off-by: Rafael J. Wysocki

ACPI / processor: Introduce invalid_logical_cpuid()

2015-05-13T21:28:14Z

In ACPI processor drivers, we use direct comparisons of cpu logical id with -1 which are error prone in case logical cpuid is accidentally assinged an error code and prevents us from returning an error-encoding cpuid directly in some cases. So introduce invalid_logical_cpuid() to identify cpu with invalid logical cpu num, then it will be used to replace the direct comparisons with -1. Signed-off-by: Hanjun Guo Signed-off-by: Rafael J. Wysocki

ACPI / processor: Introduce phys_cpuid_t for CPU hardware ID

2015-03-26T15:12:51Z

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