2019-06-04 08:11:33 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
ACPI / processor: Use common hotplug infrastructure
Split the ACPI processor driver into two parts, one that is
non-modular, resides in the ACPI core and handles the enumeration
and hotplug of processors and one that implements the rest of the
existing processor driver functionality.
The non-modular part uses an ACPI scan handler object to enumerate
processors on the basis of information provided by the ACPI namespace
and to hook up with the common ACPI hotplug infrastructure. It also
populates the ACPI handle of each processor device having a
corresponding object in the ACPI namespace, which allows the driver
proper to bind to those devices, and makes the driver bind to them
if it is readily available (i.e. loaded) when the scan handler's
.attach() routine is running.
There are a few reasons to make this change.
First, switching the ACPI processor driver to using the common ACPI
hotplug infrastructure reduces code duplication and size considerably,
even though a new file is created along with a header comment etc.
Second, since the common hotplug code attempts to offline devices
before starting the (non-reversible) removal procedure, it will abort
(and possibly roll back) hot-remove operations involving processors
if cpu_down() returns an error code for one of them instead of
continuing them blindly (if /sys/firmware/acpi/hotplug/force_remove
is unset). That is a more desirable behavior than what the current
code does.
Finally, the separation of the scan/hotplug part from the driver
proper makes it possible to simplify the driver's .remove() routine,
because it doesn't need to worry about the possible cleanup related
to processor removal any more (the scan/hotplug part is responsible
for that now) and can handle device removal and driver removal
symmetricaly (i.e. as appropriate).
Some user-visible changes in sysfs are made (for example, the
'sysdev' link from the ACPI device node to the processor device's
directory is gone and a 'physical_node' link is present instead
and a corresponding 'firmware_node' is present in the processor
device's directory, the processor driver is now visible under
/sys/bus/cpu/drivers/ and bound to the processor device), but
that shouldn't affect the functionality that users care about
(frequency scaling, C-states and thermal management).
Tested on my venerable Toshiba Portege R500.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
2013-05-02 22:26:22 +00:00
|
|
|
/*
|
|
|
|
* acpi_processor.c - ACPI processor enumeration support
|
|
|
|
*
|
|
|
|
* Copyright (C) 2001, 2002 Andy Grover <andrew.grover@intel.com>
|
|
|
|
* Copyright (C) 2001, 2002 Paul Diefenbaugh <paul.s.diefenbaugh@intel.com>
|
|
|
|
* Copyright (C) 2004 Dominik Brodowski <linux@brodo.de>
|
|
|
|
* Copyright (C) 2004 Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
|
|
|
|
* Copyright (C) 2013, Intel Corporation
|
|
|
|
* Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/acpi.h>
|
|
|
|
#include <linux/device.h>
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/pci.h>
|
|
|
|
|
|
|
|
#include <acpi/processor.h>
|
|
|
|
|
|
|
|
#include <asm/cpu.h>
|
|
|
|
|
|
|
|
#include "internal.h"
|
|
|
|
|
|
|
|
#define _COMPONENT ACPI_PROCESSOR_COMPONENT
|
|
|
|
|
|
|
|
ACPI_MODULE_NAME("processor");
|
|
|
|
|
2013-05-30 19:55:46 +00:00
|
|
|
DEFINE_PER_CPU(struct acpi_processor *, processors);
|
|
|
|
EXPORT_PER_CPU_SYMBOL(processors);
|
|
|
|
|
ACPI / processor: Use common hotplug infrastructure
Split the ACPI processor driver into two parts, one that is
non-modular, resides in the ACPI core and handles the enumeration
and hotplug of processors and one that implements the rest of the
existing processor driver functionality.
The non-modular part uses an ACPI scan handler object to enumerate
processors on the basis of information provided by the ACPI namespace
and to hook up with the common ACPI hotplug infrastructure. It also
populates the ACPI handle of each processor device having a
corresponding object in the ACPI namespace, which allows the driver
proper to bind to those devices, and makes the driver bind to them
if it is readily available (i.e. loaded) when the scan handler's
.attach() routine is running.
There are a few reasons to make this change.
First, switching the ACPI processor driver to using the common ACPI
hotplug infrastructure reduces code duplication and size considerably,
even though a new file is created along with a header comment etc.
Second, since the common hotplug code attempts to offline devices
before starting the (non-reversible) removal procedure, it will abort
(and possibly roll back) hot-remove operations involving processors
if cpu_down() returns an error code for one of them instead of
continuing them blindly (if /sys/firmware/acpi/hotplug/force_remove
is unset). That is a more desirable behavior than what the current
code does.
Finally, the separation of the scan/hotplug part from the driver
proper makes it possible to simplify the driver's .remove() routine,
because it doesn't need to worry about the possible cleanup related
to processor removal any more (the scan/hotplug part is responsible
for that now) and can handle device removal and driver removal
symmetricaly (i.e. as appropriate).
Some user-visible changes in sysfs are made (for example, the
'sysdev' link from the ACPI device node to the processor device's
directory is gone and a 'physical_node' link is present instead
and a corresponding 'firmware_node' is present in the processor
device's directory, the processor driver is now visible under
/sys/bus/cpu/drivers/ and bound to the processor device), but
that shouldn't affect the functionality that users care about
(frequency scaling, C-states and thermal management).
Tested on my venerable Toshiba Portege R500.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
2013-05-02 22:26:22 +00:00
|
|
|
/* --------------------------------------------------------------------------
|
|
|
|
Errata Handling
|
|
|
|
-------------------------------------------------------------------------- */
|
|
|
|
|
|
|
|
struct acpi_processor_errata errata __read_mostly;
|
|
|
|
EXPORT_SYMBOL_GPL(errata);
|
|
|
|
|
|
|
|
static int acpi_processor_errata_piix4(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
u8 value1 = 0;
|
|
|
|
u8 value2 = 0;
|
|
|
|
|
|
|
|
|
|
|
|
if (!dev)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Note that 'dev' references the PIIX4 ACPI Controller.
|
|
|
|
*/
|
|
|
|
|
|
|
|
switch (dev->revision) {
|
|
|
|
case 0:
|
|
|
|
ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Found PIIX4 A-step\n"));
|
|
|
|
break;
|
|
|
|
case 1:
|
|
|
|
ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Found PIIX4 B-step\n"));
|
|
|
|
break;
|
|
|
|
case 2:
|
|
|
|
ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Found PIIX4E\n"));
|
|
|
|
break;
|
|
|
|
case 3:
|
|
|
|
ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Found PIIX4M\n"));
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Found unknown PIIX4\n"));
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
switch (dev->revision) {
|
|
|
|
|
|
|
|
case 0: /* PIIX4 A-step */
|
|
|
|
case 1: /* PIIX4 B-step */
|
|
|
|
/*
|
|
|
|
* See specification changes #13 ("Manual Throttle Duty Cycle")
|
|
|
|
* and #14 ("Enabling and Disabling Manual Throttle"), plus
|
|
|
|
* erratum #5 ("STPCLK# Deassertion Time") from the January
|
|
|
|
* 2002 PIIX4 specification update. Applies to only older
|
|
|
|
* PIIX4 models.
|
|
|
|
*/
|
|
|
|
errata.piix4.throttle = 1;
|
2020-07-07 20:09:37 +00:00
|
|
|
fallthrough;
|
ACPI / processor: Use common hotplug infrastructure
Split the ACPI processor driver into two parts, one that is
non-modular, resides in the ACPI core and handles the enumeration
and hotplug of processors and one that implements the rest of the
existing processor driver functionality.
The non-modular part uses an ACPI scan handler object to enumerate
processors on the basis of information provided by the ACPI namespace
and to hook up with the common ACPI hotplug infrastructure. It also
populates the ACPI handle of each processor device having a
corresponding object in the ACPI namespace, which allows the driver
proper to bind to those devices, and makes the driver bind to them
if it is readily available (i.e. loaded) when the scan handler's
.attach() routine is running.
There are a few reasons to make this change.
First, switching the ACPI processor driver to using the common ACPI
hotplug infrastructure reduces code duplication and size considerably,
even though a new file is created along with a header comment etc.
Second, since the common hotplug code attempts to offline devices
before starting the (non-reversible) removal procedure, it will abort
(and possibly roll back) hot-remove operations involving processors
if cpu_down() returns an error code for one of them instead of
continuing them blindly (if /sys/firmware/acpi/hotplug/force_remove
is unset). That is a more desirable behavior than what the current
code does.
Finally, the separation of the scan/hotplug part from the driver
proper makes it possible to simplify the driver's .remove() routine,
because it doesn't need to worry about the possible cleanup related
to processor removal any more (the scan/hotplug part is responsible
for that now) and can handle device removal and driver removal
symmetricaly (i.e. as appropriate).
Some user-visible changes in sysfs are made (for example, the
'sysdev' link from the ACPI device node to the processor device's
directory is gone and a 'physical_node' link is present instead
and a corresponding 'firmware_node' is present in the processor
device's directory, the processor driver is now visible under
/sys/bus/cpu/drivers/ and bound to the processor device), but
that shouldn't affect the functionality that users care about
(frequency scaling, C-states and thermal management).
Tested on my venerable Toshiba Portege R500.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
2013-05-02 22:26:22 +00:00
|
|
|
|
|
|
|
case 2: /* PIIX4E */
|
|
|
|
case 3: /* PIIX4M */
|
|
|
|
/*
|
|
|
|
* See erratum #18 ("C3 Power State/BMIDE and Type-F DMA
|
|
|
|
* Livelock") from the January 2002 PIIX4 specification update.
|
|
|
|
* Applies to all PIIX4 models.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* BM-IDE
|
|
|
|
* ------
|
|
|
|
* Find the PIIX4 IDE Controller and get the Bus Master IDE
|
|
|
|
* Status register address. We'll use this later to read
|
|
|
|
* each IDE controller's DMA status to make sure we catch all
|
|
|
|
* DMA activity.
|
|
|
|
*/
|
|
|
|
dev = pci_get_subsys(PCI_VENDOR_ID_INTEL,
|
|
|
|
PCI_DEVICE_ID_INTEL_82371AB,
|
|
|
|
PCI_ANY_ID, PCI_ANY_ID, NULL);
|
|
|
|
if (dev) {
|
|
|
|
errata.piix4.bmisx = pci_resource_start(dev, 4);
|
|
|
|
pci_dev_put(dev);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Type-F DMA
|
|
|
|
* ----------
|
|
|
|
* Find the PIIX4 ISA Controller and read the Motherboard
|
|
|
|
* DMA controller's status to see if Type-F (Fast) DMA mode
|
|
|
|
* is enabled (bit 7) on either channel. Note that we'll
|
|
|
|
* disable C3 support if this is enabled, as some legacy
|
|
|
|
* devices won't operate well if fast DMA is disabled.
|
|
|
|
*/
|
|
|
|
dev = pci_get_subsys(PCI_VENDOR_ID_INTEL,
|
|
|
|
PCI_DEVICE_ID_INTEL_82371AB_0,
|
|
|
|
PCI_ANY_ID, PCI_ANY_ID, NULL);
|
|
|
|
if (dev) {
|
|
|
|
pci_read_config_byte(dev, 0x76, &value1);
|
|
|
|
pci_read_config_byte(dev, 0x77, &value2);
|
|
|
|
if ((value1 & 0x80) || (value2 & 0x80))
|
|
|
|
errata.piix4.fdma = 1;
|
|
|
|
pci_dev_put(dev);
|
|
|
|
}
|
|
|
|
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (errata.piix4.bmisx)
|
|
|
|
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
|
|
|
|
"Bus master activity detection (BM-IDE) erratum enabled\n"));
|
|
|
|
if (errata.piix4.fdma)
|
|
|
|
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
|
|
|
|
"Type-F DMA livelock erratum (C3 disabled)\n"));
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-09-02 03:57:38 +00:00
|
|
|
static int acpi_processor_errata(void)
|
ACPI / processor: Use common hotplug infrastructure
Split the ACPI processor driver into two parts, one that is
non-modular, resides in the ACPI core and handles the enumeration
and hotplug of processors and one that implements the rest of the
existing processor driver functionality.
The non-modular part uses an ACPI scan handler object to enumerate
processors on the basis of information provided by the ACPI namespace
and to hook up with the common ACPI hotplug infrastructure. It also
populates the ACPI handle of each processor device having a
corresponding object in the ACPI namespace, which allows the driver
proper to bind to those devices, and makes the driver bind to them
if it is readily available (i.e. loaded) when the scan handler's
.attach() routine is running.
There are a few reasons to make this change.
First, switching the ACPI processor driver to using the common ACPI
hotplug infrastructure reduces code duplication and size considerably,
even though a new file is created along with a header comment etc.
Second, since the common hotplug code attempts to offline devices
before starting the (non-reversible) removal procedure, it will abort
(and possibly roll back) hot-remove operations involving processors
if cpu_down() returns an error code for one of them instead of
continuing them blindly (if /sys/firmware/acpi/hotplug/force_remove
is unset). That is a more desirable behavior than what the current
code does.
Finally, the separation of the scan/hotplug part from the driver
proper makes it possible to simplify the driver's .remove() routine,
because it doesn't need to worry about the possible cleanup related
to processor removal any more (the scan/hotplug part is responsible
for that now) and can handle device removal and driver removal
symmetricaly (i.e. as appropriate).
Some user-visible changes in sysfs are made (for example, the
'sysdev' link from the ACPI device node to the processor device's
directory is gone and a 'physical_node' link is present instead
and a corresponding 'firmware_node' is present in the processor
device's directory, the processor driver is now visible under
/sys/bus/cpu/drivers/ and bound to the processor device), but
that shouldn't affect the functionality that users care about
(frequency scaling, C-states and thermal management).
Tested on my venerable Toshiba Portege R500.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
2013-05-02 22:26:22 +00:00
|
|
|
{
|
|
|
|
int result = 0;
|
|
|
|
struct pci_dev *dev = NULL;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* PIIX4
|
|
|
|
*/
|
|
|
|
dev = pci_get_subsys(PCI_VENDOR_ID_INTEL,
|
|
|
|
PCI_DEVICE_ID_INTEL_82371AB_3, PCI_ANY_ID,
|
|
|
|
PCI_ANY_ID, NULL);
|
|
|
|
if (dev) {
|
|
|
|
result = acpi_processor_errata_piix4(dev);
|
|
|
|
pci_dev_put(dev);
|
|
|
|
}
|
|
|
|
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* --------------------------------------------------------------------------
|
|
|
|
Initialization
|
|
|
|
-------------------------------------------------------------------------- */
|
|
|
|
|
|
|
|
#ifdef CONFIG_ACPI_HOTPLUG_CPU
|
2015-09-09 20:27:06 +00:00
|
|
|
int __weak acpi_map_cpu(acpi_handle handle,
|
2017-02-06 17:01:51 +00:00
|
|
|
phys_cpuid_t physid, u32 acpi_id, int *pcpu)
|
2015-09-09 20:27:06 +00:00
|
|
|
{
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
|
|
|
int __weak acpi_unmap_cpu(int cpu)
|
|
|
|
{
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
|
|
|
int __weak arch_register_cpu(int cpu)
|
|
|
|
{
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
|
|
|
void __weak arch_unregister_cpu(int cpu) {}
|
|
|
|
|
ACPI / processor: Use common hotplug infrastructure
Split the ACPI processor driver into two parts, one that is
non-modular, resides in the ACPI core and handles the enumeration
and hotplug of processors and one that implements the rest of the
existing processor driver functionality.
The non-modular part uses an ACPI scan handler object to enumerate
processors on the basis of information provided by the ACPI namespace
and to hook up with the common ACPI hotplug infrastructure. It also
populates the ACPI handle of each processor device having a
corresponding object in the ACPI namespace, which allows the driver
proper to bind to those devices, and makes the driver bind to them
if it is readily available (i.e. loaded) when the scan handler's
.attach() routine is running.
There are a few reasons to make this change.
First, switching the ACPI processor driver to using the common ACPI
hotplug infrastructure reduces code duplication and size considerably,
even though a new file is created along with a header comment etc.
Second, since the common hotplug code attempts to offline devices
before starting the (non-reversible) removal procedure, it will abort
(and possibly roll back) hot-remove operations involving processors
if cpu_down() returns an error code for one of them instead of
continuing them blindly (if /sys/firmware/acpi/hotplug/force_remove
is unset). That is a more desirable behavior than what the current
code does.
Finally, the separation of the scan/hotplug part from the driver
proper makes it possible to simplify the driver's .remove() routine,
because it doesn't need to worry about the possible cleanup related
to processor removal any more (the scan/hotplug part is responsible
for that now) and can handle device removal and driver removal
symmetricaly (i.e. as appropriate).
Some user-visible changes in sysfs are made (for example, the
'sysdev' link from the ACPI device node to the processor device's
directory is gone and a 'physical_node' link is present instead
and a corresponding 'firmware_node' is present in the processor
device's directory, the processor driver is now visible under
/sys/bus/cpu/drivers/ and bound to the processor device), but
that shouldn't affect the functionality that users care about
(frequency scaling, C-states and thermal management).
Tested on my venerable Toshiba Portege R500.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
2013-05-02 22:26:22 +00:00
|
|
|
static int acpi_processor_hotadd_init(struct acpi_processor *pr)
|
|
|
|
{
|
|
|
|
unsigned long long sta;
|
|
|
|
acpi_status status;
|
|
|
|
int ret;
|
|
|
|
|
2015-05-13 08:19:30 +00:00
|
|
|
if (invalid_phys_cpuid(pr->phys_id))
|
2014-04-30 07:46:33 +00:00
|
|
|
return -ENODEV;
|
|
|
|
|
ACPI / processor: Use common hotplug infrastructure
Split the ACPI processor driver into two parts, one that is
non-modular, resides in the ACPI core and handles the enumeration
and hotplug of processors and one that implements the rest of the
existing processor driver functionality.
The non-modular part uses an ACPI scan handler object to enumerate
processors on the basis of information provided by the ACPI namespace
and to hook up with the common ACPI hotplug infrastructure. It also
populates the ACPI handle of each processor device having a
corresponding object in the ACPI namespace, which allows the driver
proper to bind to those devices, and makes the driver bind to them
if it is readily available (i.e. loaded) when the scan handler's
.attach() routine is running.
There are a few reasons to make this change.
First, switching the ACPI processor driver to using the common ACPI
hotplug infrastructure reduces code duplication and size considerably,
even though a new file is created along with a header comment etc.
Second, since the common hotplug code attempts to offline devices
before starting the (non-reversible) removal procedure, it will abort
(and possibly roll back) hot-remove operations involving processors
if cpu_down() returns an error code for one of them instead of
continuing them blindly (if /sys/firmware/acpi/hotplug/force_remove
is unset). That is a more desirable behavior than what the current
code does.
Finally, the separation of the scan/hotplug part from the driver
proper makes it possible to simplify the driver's .remove() routine,
because it doesn't need to worry about the possible cleanup related
to processor removal any more (the scan/hotplug part is responsible
for that now) and can handle device removal and driver removal
symmetricaly (i.e. as appropriate).
Some user-visible changes in sysfs are made (for example, the
'sysdev' link from the ACPI device node to the processor device's
directory is gone and a 'physical_node' link is present instead
and a corresponding 'firmware_node' is present in the processor
device's directory, the processor driver is now visible under
/sys/bus/cpu/drivers/ and bound to the processor device), but
that shouldn't affect the functionality that users care about
(frequency scaling, C-states and thermal management).
Tested on my venerable Toshiba Portege R500.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
2013-05-02 22:26:22 +00:00
|
|
|
status = acpi_evaluate_integer(pr->handle, "_STA", NULL, &sta);
|
|
|
|
if (ACPI_FAILURE(status) || !(sta & ACPI_STA_DEVICE_PRESENT))
|
|
|
|
return -ENODEV;
|
|
|
|
|
ACPI / processor: Acquire writer lock to update CPU maps
CPU system maps are protected with reader/writer locks. The reader
lock, get_online_cpus(), assures that the maps are not updated while
holding the lock. The writer lock, cpu_hotplug_begin(), is used to
udpate the cpu maps along with cpu_maps_update_begin().
However, the ACPI processor handler updates the cpu maps without
holding the the writer lock.
acpi_map_lsapic() is called from acpi_processor_hotadd_init() to
update cpu_possible_mask and cpu_present_mask. acpi_unmap_lsapic()
is called from acpi_processor_remove() to update cpu_possible_mask.
Currently, they are either unprotected or protected with the reader
lock, which is not correct.
For example, the get_online_cpus() below is supposed to assure that
cpu_possible_mask is not changed while the code is iterating with
for_each_possible_cpu().
get_online_cpus();
for_each_possible_cpu(cpu) {
:
}
put_online_cpus();
However, this lock has no protection with CPU hotplug since the ACPI
processor handler does not use the writer lock when it updates
cpu_possible_mask. The reader lock does not serialize within the
readers.
This patch protects them with the writer lock with cpu_hotplug_begin()
along with cpu_maps_update_begin(), which must be held before calling
cpu_hotplug_begin(). It also protects arch_register_cpu() /
arch_unregister_cpu(), which creates / deletes a sysfs cpu device
interface. For this purpose it changes cpu_hotplug_begin() and
cpu_hotplug_done() to global and exports them in cpu.h.
Signed-off-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-08-12 15:45:53 +00:00
|
|
|
cpu_maps_update_begin();
|
|
|
|
cpu_hotplug_begin();
|
|
|
|
|
2017-02-06 17:01:51 +00:00
|
|
|
ret = acpi_map_cpu(pr->handle, pr->phys_id, pr->acpi_id, &pr->id);
|
ACPI / processor: Use common hotplug infrastructure
Split the ACPI processor driver into two parts, one that is
non-modular, resides in the ACPI core and handles the enumeration
and hotplug of processors and one that implements the rest of the
existing processor driver functionality.
The non-modular part uses an ACPI scan handler object to enumerate
processors on the basis of information provided by the ACPI namespace
and to hook up with the common ACPI hotplug infrastructure. It also
populates the ACPI handle of each processor device having a
corresponding object in the ACPI namespace, which allows the driver
proper to bind to those devices, and makes the driver bind to them
if it is readily available (i.e. loaded) when the scan handler's
.attach() routine is running.
There are a few reasons to make this change.
First, switching the ACPI processor driver to using the common ACPI
hotplug infrastructure reduces code duplication and size considerably,
even though a new file is created along with a header comment etc.
Second, since the common hotplug code attempts to offline devices
before starting the (non-reversible) removal procedure, it will abort
(and possibly roll back) hot-remove operations involving processors
if cpu_down() returns an error code for one of them instead of
continuing them blindly (if /sys/firmware/acpi/hotplug/force_remove
is unset). That is a more desirable behavior than what the current
code does.
Finally, the separation of the scan/hotplug part from the driver
proper makes it possible to simplify the driver's .remove() routine,
because it doesn't need to worry about the possible cleanup related
to processor removal any more (the scan/hotplug part is responsible
for that now) and can handle device removal and driver removal
symmetricaly (i.e. as appropriate).
Some user-visible changes in sysfs are made (for example, the
'sysdev' link from the ACPI device node to the processor device's
directory is gone and a 'physical_node' link is present instead
and a corresponding 'firmware_node' is present in the processor
device's directory, the processor driver is now visible under
/sys/bus/cpu/drivers/ and bound to the processor device), but
that shouldn't affect the functionality that users care about
(frequency scaling, C-states and thermal management).
Tested on my venerable Toshiba Portege R500.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
2013-05-02 22:26:22 +00:00
|
|
|
if (ret)
|
ACPI / processor: Acquire writer lock to update CPU maps
CPU system maps are protected with reader/writer locks. The reader
lock, get_online_cpus(), assures that the maps are not updated while
holding the lock. The writer lock, cpu_hotplug_begin(), is used to
udpate the cpu maps along with cpu_maps_update_begin().
However, the ACPI processor handler updates the cpu maps without
holding the the writer lock.
acpi_map_lsapic() is called from acpi_processor_hotadd_init() to
update cpu_possible_mask and cpu_present_mask. acpi_unmap_lsapic()
is called from acpi_processor_remove() to update cpu_possible_mask.
Currently, they are either unprotected or protected with the reader
lock, which is not correct.
For example, the get_online_cpus() below is supposed to assure that
cpu_possible_mask is not changed while the code is iterating with
for_each_possible_cpu().
get_online_cpus();
for_each_possible_cpu(cpu) {
:
}
put_online_cpus();
However, this lock has no protection with CPU hotplug since the ACPI
processor handler does not use the writer lock when it updates
cpu_possible_mask. The reader lock does not serialize within the
readers.
This patch protects them with the writer lock with cpu_hotplug_begin()
along with cpu_maps_update_begin(), which must be held before calling
cpu_hotplug_begin(). It also protects arch_register_cpu() /
arch_unregister_cpu(), which creates / deletes a sysfs cpu device
interface. For this purpose it changes cpu_hotplug_begin() and
cpu_hotplug_done() to global and exports them in cpu.h.
Signed-off-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-08-12 15:45:53 +00:00
|
|
|
goto out;
|
ACPI / processor: Use common hotplug infrastructure
Split the ACPI processor driver into two parts, one that is
non-modular, resides in the ACPI core and handles the enumeration
and hotplug of processors and one that implements the rest of the
existing processor driver functionality.
The non-modular part uses an ACPI scan handler object to enumerate
processors on the basis of information provided by the ACPI namespace
and to hook up with the common ACPI hotplug infrastructure. It also
populates the ACPI handle of each processor device having a
corresponding object in the ACPI namespace, which allows the driver
proper to bind to those devices, and makes the driver bind to them
if it is readily available (i.e. loaded) when the scan handler's
.attach() routine is running.
There are a few reasons to make this change.
First, switching the ACPI processor driver to using the common ACPI
hotplug infrastructure reduces code duplication and size considerably,
even though a new file is created along with a header comment etc.
Second, since the common hotplug code attempts to offline devices
before starting the (non-reversible) removal procedure, it will abort
(and possibly roll back) hot-remove operations involving processors
if cpu_down() returns an error code for one of them instead of
continuing them blindly (if /sys/firmware/acpi/hotplug/force_remove
is unset). That is a more desirable behavior than what the current
code does.
Finally, the separation of the scan/hotplug part from the driver
proper makes it possible to simplify the driver's .remove() routine,
because it doesn't need to worry about the possible cleanup related
to processor removal any more (the scan/hotplug part is responsible
for that now) and can handle device removal and driver removal
symmetricaly (i.e. as appropriate).
Some user-visible changes in sysfs are made (for example, the
'sysdev' link from the ACPI device node to the processor device's
directory is gone and a 'physical_node' link is present instead
and a corresponding 'firmware_node' is present in the processor
device's directory, the processor driver is now visible under
/sys/bus/cpu/drivers/ and bound to the processor device), but
that shouldn't affect the functionality that users care about
(frequency scaling, C-states and thermal management).
Tested on my venerable Toshiba Portege R500.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
2013-05-02 22:26:22 +00:00
|
|
|
|
|
|
|
ret = arch_register_cpu(pr->id);
|
|
|
|
if (ret) {
|
2015-01-04 10:55:03 +00:00
|
|
|
acpi_unmap_cpu(pr->id);
|
ACPI / processor: Acquire writer lock to update CPU maps
CPU system maps are protected with reader/writer locks. The reader
lock, get_online_cpus(), assures that the maps are not updated while
holding the lock. The writer lock, cpu_hotplug_begin(), is used to
udpate the cpu maps along with cpu_maps_update_begin().
However, the ACPI processor handler updates the cpu maps without
holding the the writer lock.
acpi_map_lsapic() is called from acpi_processor_hotadd_init() to
update cpu_possible_mask and cpu_present_mask. acpi_unmap_lsapic()
is called from acpi_processor_remove() to update cpu_possible_mask.
Currently, they are either unprotected or protected with the reader
lock, which is not correct.
For example, the get_online_cpus() below is supposed to assure that
cpu_possible_mask is not changed while the code is iterating with
for_each_possible_cpu().
get_online_cpus();
for_each_possible_cpu(cpu) {
:
}
put_online_cpus();
However, this lock has no protection with CPU hotplug since the ACPI
processor handler does not use the writer lock when it updates
cpu_possible_mask. The reader lock does not serialize within the
readers.
This patch protects them with the writer lock with cpu_hotplug_begin()
along with cpu_maps_update_begin(), which must be held before calling
cpu_hotplug_begin(). It also protects arch_register_cpu() /
arch_unregister_cpu(), which creates / deletes a sysfs cpu device
interface. For this purpose it changes cpu_hotplug_begin() and
cpu_hotplug_done() to global and exports them in cpu.h.
Signed-off-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-08-12 15:45:53 +00:00
|
|
|
goto out;
|
ACPI / processor: Use common hotplug infrastructure
Split the ACPI processor driver into two parts, one that is
non-modular, resides in the ACPI core and handles the enumeration
and hotplug of processors and one that implements the rest of the
existing processor driver functionality.
The non-modular part uses an ACPI scan handler object to enumerate
processors on the basis of information provided by the ACPI namespace
and to hook up with the common ACPI hotplug infrastructure. It also
populates the ACPI handle of each processor device having a
corresponding object in the ACPI namespace, which allows the driver
proper to bind to those devices, and makes the driver bind to them
if it is readily available (i.e. loaded) when the scan handler's
.attach() routine is running.
There are a few reasons to make this change.
First, switching the ACPI processor driver to using the common ACPI
hotplug infrastructure reduces code duplication and size considerably,
even though a new file is created along with a header comment etc.
Second, since the common hotplug code attempts to offline devices
before starting the (non-reversible) removal procedure, it will abort
(and possibly roll back) hot-remove operations involving processors
if cpu_down() returns an error code for one of them instead of
continuing them blindly (if /sys/firmware/acpi/hotplug/force_remove
is unset). That is a more desirable behavior than what the current
code does.
Finally, the separation of the scan/hotplug part from the driver
proper makes it possible to simplify the driver's .remove() routine,
because it doesn't need to worry about the possible cleanup related
to processor removal any more (the scan/hotplug part is responsible
for that now) and can handle device removal and driver removal
symmetricaly (i.e. as appropriate).
Some user-visible changes in sysfs are made (for example, the
'sysdev' link from the ACPI device node to the processor device's
directory is gone and a 'physical_node' link is present instead
and a corresponding 'firmware_node' is present in the processor
device's directory, the processor driver is now visible under
/sys/bus/cpu/drivers/ and bound to the processor device), but
that shouldn't affect the functionality that users care about
(frequency scaling, C-states and thermal management).
Tested on my venerable Toshiba Portege R500.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
2013-05-02 22:26:22 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* CPU got hot-added, but cpu_data is not initialized yet. Set a flag
|
|
|
|
* to delay cpu_idle/throttling initialization and do it when the CPU
|
|
|
|
* gets online for the first time.
|
|
|
|
*/
|
|
|
|
pr_info("CPU%d has been hot-added\n", pr->id);
|
|
|
|
pr->flags.need_hotplug_init = 1;
|
ACPI / processor: Acquire writer lock to update CPU maps
CPU system maps are protected with reader/writer locks. The reader
lock, get_online_cpus(), assures that the maps are not updated while
holding the lock. The writer lock, cpu_hotplug_begin(), is used to
udpate the cpu maps along with cpu_maps_update_begin().
However, the ACPI processor handler updates the cpu maps without
holding the the writer lock.
acpi_map_lsapic() is called from acpi_processor_hotadd_init() to
update cpu_possible_mask and cpu_present_mask. acpi_unmap_lsapic()
is called from acpi_processor_remove() to update cpu_possible_mask.
Currently, they are either unprotected or protected with the reader
lock, which is not correct.
For example, the get_online_cpus() below is supposed to assure that
cpu_possible_mask is not changed while the code is iterating with
for_each_possible_cpu().
get_online_cpus();
for_each_possible_cpu(cpu) {
:
}
put_online_cpus();
However, this lock has no protection with CPU hotplug since the ACPI
processor handler does not use the writer lock when it updates
cpu_possible_mask. The reader lock does not serialize within the
readers.
This patch protects them with the writer lock with cpu_hotplug_begin()
along with cpu_maps_update_begin(), which must be held before calling
cpu_hotplug_begin(). It also protects arch_register_cpu() /
arch_unregister_cpu(), which creates / deletes a sysfs cpu device
interface. For this purpose it changes cpu_hotplug_begin() and
cpu_hotplug_done() to global and exports them in cpu.h.
Signed-off-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-08-12 15:45:53 +00:00
|
|
|
|
|
|
|
out:
|
|
|
|
cpu_hotplug_done();
|
|
|
|
cpu_maps_update_done();
|
|
|
|
return ret;
|
ACPI / processor: Use common hotplug infrastructure
Split the ACPI processor driver into two parts, one that is
non-modular, resides in the ACPI core and handles the enumeration
and hotplug of processors and one that implements the rest of the
existing processor driver functionality.
The non-modular part uses an ACPI scan handler object to enumerate
processors on the basis of information provided by the ACPI namespace
and to hook up with the common ACPI hotplug infrastructure. It also
populates the ACPI handle of each processor device having a
corresponding object in the ACPI namespace, which allows the driver
proper to bind to those devices, and makes the driver bind to them
if it is readily available (i.e. loaded) when the scan handler's
.attach() routine is running.
There are a few reasons to make this change.
First, switching the ACPI processor driver to using the common ACPI
hotplug infrastructure reduces code duplication and size considerably,
even though a new file is created along with a header comment etc.
Second, since the common hotplug code attempts to offline devices
before starting the (non-reversible) removal procedure, it will abort
(and possibly roll back) hot-remove operations involving processors
if cpu_down() returns an error code for one of them instead of
continuing them blindly (if /sys/firmware/acpi/hotplug/force_remove
is unset). That is a more desirable behavior than what the current
code does.
Finally, the separation of the scan/hotplug part from the driver
proper makes it possible to simplify the driver's .remove() routine,
because it doesn't need to worry about the possible cleanup related
to processor removal any more (the scan/hotplug part is responsible
for that now) and can handle device removal and driver removal
symmetricaly (i.e. as appropriate).
Some user-visible changes in sysfs are made (for example, the
'sysdev' link from the ACPI device node to the processor device's
directory is gone and a 'physical_node' link is present instead
and a corresponding 'firmware_node' is present in the processor
device's directory, the processor driver is now visible under
/sys/bus/cpu/drivers/ and bound to the processor device), but
that shouldn't affect the functionality that users care about
(frequency scaling, C-states and thermal management).
Tested on my venerable Toshiba Portege R500.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
2013-05-02 22:26:22 +00:00
|
|
|
}
|
|
|
|
#else
|
|
|
|
static inline int acpi_processor_hotadd_init(struct acpi_processor *pr)
|
|
|
|
{
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
#endif /* CONFIG_ACPI_HOTPLUG_CPU */
|
|
|
|
|
|
|
|
static int acpi_processor_get_info(struct acpi_device *device)
|
|
|
|
{
|
|
|
|
union acpi_object object = { 0 };
|
|
|
|
struct acpi_buffer buffer = { sizeof(union acpi_object), &object };
|
|
|
|
struct acpi_processor *pr = acpi_driver_data(device);
|
2015-05-11 04:17:16 +00:00
|
|
|
int device_declaration = 0;
|
ACPI / processor: Use common hotplug infrastructure
Split the ACPI processor driver into two parts, one that is
non-modular, resides in the ACPI core and handles the enumeration
and hotplug of processors and one that implements the rest of the
existing processor driver functionality.
The non-modular part uses an ACPI scan handler object to enumerate
processors on the basis of information provided by the ACPI namespace
and to hook up with the common ACPI hotplug infrastructure. It also
populates the ACPI handle of each processor device having a
corresponding object in the ACPI namespace, which allows the driver
proper to bind to those devices, and makes the driver bind to them
if it is readily available (i.e. loaded) when the scan handler's
.attach() routine is running.
There are a few reasons to make this change.
First, switching the ACPI processor driver to using the common ACPI
hotplug infrastructure reduces code duplication and size considerably,
even though a new file is created along with a header comment etc.
Second, since the common hotplug code attempts to offline devices
before starting the (non-reversible) removal procedure, it will abort
(and possibly roll back) hot-remove operations involving processors
if cpu_down() returns an error code for one of them instead of
continuing them blindly (if /sys/firmware/acpi/hotplug/force_remove
is unset). That is a more desirable behavior than what the current
code does.
Finally, the separation of the scan/hotplug part from the driver
proper makes it possible to simplify the driver's .remove() routine,
because it doesn't need to worry about the possible cleanup related
to processor removal any more (the scan/hotplug part is responsible
for that now) and can handle device removal and driver removal
symmetricaly (i.e. as appropriate).
Some user-visible changes in sysfs are made (for example, the
'sysdev' link from the ACPI device node to the processor device's
directory is gone and a 'physical_node' link is present instead
and a corresponding 'firmware_node' is present in the processor
device's directory, the processor driver is now visible under
/sys/bus/cpu/drivers/ and bound to the processor device), but
that shouldn't affect the functionality that users care about
(frequency scaling, C-states and thermal management).
Tested on my venerable Toshiba Portege R500.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
2013-05-02 22:26:22 +00:00
|
|
|
acpi_status status = AE_OK;
|
|
|
|
static int cpu0_initialized;
|
2013-09-03 00:32:09 +00:00
|
|
|
unsigned long long value;
|
ACPI / processor: Use common hotplug infrastructure
Split the ACPI processor driver into two parts, one that is
non-modular, resides in the ACPI core and handles the enumeration
and hotplug of processors and one that implements the rest of the
existing processor driver functionality.
The non-modular part uses an ACPI scan handler object to enumerate
processors on the basis of information provided by the ACPI namespace
and to hook up with the common ACPI hotplug infrastructure. It also
populates the ACPI handle of each processor device having a
corresponding object in the ACPI namespace, which allows the driver
proper to bind to those devices, and makes the driver bind to them
if it is readily available (i.e. loaded) when the scan handler's
.attach() routine is running.
There are a few reasons to make this change.
First, switching the ACPI processor driver to using the common ACPI
hotplug infrastructure reduces code duplication and size considerably,
even though a new file is created along with a header comment etc.
Second, since the common hotplug code attempts to offline devices
before starting the (non-reversible) removal procedure, it will abort
(and possibly roll back) hot-remove operations involving processors
if cpu_down() returns an error code for one of them instead of
continuing them blindly (if /sys/firmware/acpi/hotplug/force_remove
is unset). That is a more desirable behavior than what the current
code does.
Finally, the separation of the scan/hotplug part from the driver
proper makes it possible to simplify the driver's .remove() routine,
because it doesn't need to worry about the possible cleanup related
to processor removal any more (the scan/hotplug part is responsible
for that now) and can handle device removal and driver removal
symmetricaly (i.e. as appropriate).
Some user-visible changes in sysfs are made (for example, the
'sysdev' link from the ACPI device node to the processor device's
directory is gone and a 'physical_node' link is present instead
and a corresponding 'firmware_node' is present in the processor
device's directory, the processor driver is now visible under
/sys/bus/cpu/drivers/ and bound to the processor device), but
that shouldn't affect the functionality that users care about
(frequency scaling, C-states and thermal management).
Tested on my venerable Toshiba Portege R500.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
2013-05-02 22:26:22 +00:00
|
|
|
|
2013-09-02 03:57:38 +00:00
|
|
|
acpi_processor_errata();
|
ACPI / processor: Use common hotplug infrastructure
Split the ACPI processor driver into two parts, one that is
non-modular, resides in the ACPI core and handles the enumeration
and hotplug of processors and one that implements the rest of the
existing processor driver functionality.
The non-modular part uses an ACPI scan handler object to enumerate
processors on the basis of information provided by the ACPI namespace
and to hook up with the common ACPI hotplug infrastructure. It also
populates the ACPI handle of each processor device having a
corresponding object in the ACPI namespace, which allows the driver
proper to bind to those devices, and makes the driver bind to them
if it is readily available (i.e. loaded) when the scan handler's
.attach() routine is running.
There are a few reasons to make this change.
First, switching the ACPI processor driver to using the common ACPI
hotplug infrastructure reduces code duplication and size considerably,
even though a new file is created along with a header comment etc.
Second, since the common hotplug code attempts to offline devices
before starting the (non-reversible) removal procedure, it will abort
(and possibly roll back) hot-remove operations involving processors
if cpu_down() returns an error code for one of them instead of
continuing them blindly (if /sys/firmware/acpi/hotplug/force_remove
is unset). That is a more desirable behavior than what the current
code does.
Finally, the separation of the scan/hotplug part from the driver
proper makes it possible to simplify the driver's .remove() routine,
because it doesn't need to worry about the possible cleanup related
to processor removal any more (the scan/hotplug part is responsible
for that now) and can handle device removal and driver removal
symmetricaly (i.e. as appropriate).
Some user-visible changes in sysfs are made (for example, the
'sysdev' link from the ACPI device node to the processor device's
directory is gone and a 'physical_node' link is present instead
and a corresponding 'firmware_node' is present in the processor
device's directory, the processor driver is now visible under
/sys/bus/cpu/drivers/ and bound to the processor device), but
that shouldn't affect the functionality that users care about
(frequency scaling, C-states and thermal management).
Tested on my venerable Toshiba Portege R500.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
2013-05-02 22:26:22 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Check to see if we have bus mastering arbitration control. This
|
|
|
|
* is required for proper C3 usage (to maintain cache coherency).
|
|
|
|
*/
|
|
|
|
if (acpi_gbl_FADT.pm2_control_block && acpi_gbl_FADT.pm2_control_length) {
|
|
|
|
pr->flags.bm_control = 1;
|
|
|
|
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
|
|
|
|
"Bus mastering arbitration control present\n"));
|
|
|
|
} else
|
|
|
|
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
|
|
|
|
"No bus mastering arbitration control\n"));
|
|
|
|
|
|
|
|
if (!strcmp(acpi_device_hid(device), ACPI_PROCESSOR_OBJECT_HID)) {
|
|
|
|
/* Declared with "Processor" statement; match ProcessorID */
|
|
|
|
status = acpi_evaluate_object(pr->handle, NULL, NULL, &buffer);
|
|
|
|
if (ACPI_FAILURE(status)) {
|
|
|
|
dev_err(&device->dev,
|
|
|
|
"Failed to evaluate processor object (0x%x)\n",
|
|
|
|
status);
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
|
|
|
pr->acpi_id = object.processor.proc_id;
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* Declared with "Device" statement; match _UID.
|
|
|
|
* Note that we don't handle string _UIDs yet.
|
|
|
|
*/
|
|
|
|
status = acpi_evaluate_integer(pr->handle, METHOD_NAME__UID,
|
|
|
|
NULL, &value);
|
|
|
|
if (ACPI_FAILURE(status)) {
|
|
|
|
dev_err(&device->dev,
|
|
|
|
"Failed to evaluate processor _UID (0x%x)\n",
|
|
|
|
status);
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
device_declaration = 1;
|
|
|
|
pr->acpi_id = value;
|
|
|
|
}
|
|
|
|
|
2017-03-03 08:02:27 +00:00
|
|
|
if (acpi_duplicate_processor_id(pr->acpi_id)) {
|
ACPI / processor: don't print errors for processorIDs == 0xff
Some platforms define their processors in this manner:
Device (SCK0)
{
Name (_HID, "ACPI0004" /* Module Device */) // _HID: Hardware ID
Name (_UID, "CPUSCK0") // _UID: Unique ID
Processor (CP00, 0x00, 0x00000410, 0x06){}
Processor (CP01, 0x02, 0x00000410, 0x06){}
Processor (CP02, 0x04, 0x00000410, 0x06){}
Processor (CP03, 0x06, 0x00000410, 0x06){}
Processor (CP04, 0x01, 0x00000410, 0x06){}
Processor (CP05, 0x03, 0x00000410, 0x06){}
Processor (CP06, 0x05, 0x00000410, 0x06){}
Processor (CP07, 0x07, 0x00000410, 0x06){}
Processor (CP08, 0xFF, 0x00000410, 0x06){}
Processor (CP09, 0xFF, 0x00000410, 0x06){}
Processor (CP0A, 0xFF, 0x00000410, 0x06){}
Processor (CP0B, 0xFF, 0x00000410, 0x06){}
...
The processors marked as 0xff are invalid, there are only 8 of them in
this case.
So do not print an error on ids == 0xff, just print an info message.
Actually, we could return ENODEV even on the first CPU with ID 0xff, but
ACPI spec does not forbid the 0xff value to be a processor ID. Given
0xff could be a correct one, we would break working systems if we
returned ENODEV.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-08-07 11:10:37 +00:00
|
|
|
if (pr->acpi_id == 0xff)
|
|
|
|
dev_info_once(&device->dev,
|
|
|
|
"Entry not well-defined, consider updating BIOS\n");
|
|
|
|
else
|
|
|
|
dev_err(&device->dev,
|
|
|
|
"Failed to get unique processor _UID (0x%x)\n",
|
|
|
|
pr->acpi_id);
|
2017-03-03 08:02:27 +00:00
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
2015-05-11 04:17:17 +00:00
|
|
|
pr->phys_id = acpi_get_phys_id(pr->handle, device_declaration,
|
|
|
|
pr->acpi_id);
|
2015-05-13 08:19:30 +00:00
|
|
|
if (invalid_phys_cpuid(pr->phys_id))
|
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 <hanjun.guo@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-04 10:55:02 +00:00
|
|
|
acpi_handle_debug(pr->handle, "failed to get CPU physical ID.\n");
|
ACPI / processor: Use common hotplug infrastructure
Split the ACPI processor driver into two parts, one that is
non-modular, resides in the ACPI core and handles the enumeration
and hotplug of processors and one that implements the rest of the
existing processor driver functionality.
The non-modular part uses an ACPI scan handler object to enumerate
processors on the basis of information provided by the ACPI namespace
and to hook up with the common ACPI hotplug infrastructure. It also
populates the ACPI handle of each processor device having a
corresponding object in the ACPI namespace, which allows the driver
proper to bind to those devices, and makes the driver bind to them
if it is readily available (i.e. loaded) when the scan handler's
.attach() routine is running.
There are a few reasons to make this change.
First, switching the ACPI processor driver to using the common ACPI
hotplug infrastructure reduces code duplication and size considerably,
even though a new file is created along with a header comment etc.
Second, since the common hotplug code attempts to offline devices
before starting the (non-reversible) removal procedure, it will abort
(and possibly roll back) hot-remove operations involving processors
if cpu_down() returns an error code for one of them instead of
continuing them blindly (if /sys/firmware/acpi/hotplug/force_remove
is unset). That is a more desirable behavior than what the current
code does.
Finally, the separation of the scan/hotplug part from the driver
proper makes it possible to simplify the driver's .remove() routine,
because it doesn't need to worry about the possible cleanup related
to processor removal any more (the scan/hotplug part is responsible
for that now) and can handle device removal and driver removal
symmetricaly (i.e. as appropriate).
Some user-visible changes in sysfs are made (for example, the
'sysdev' link from the ACPI device node to the processor device's
directory is gone and a 'physical_node' link is present instead
and a corresponding 'firmware_node' is present in the processor
device's directory, the processor driver is now visible under
/sys/bus/cpu/drivers/ and bound to the processor device), but
that shouldn't affect the functionality that users care about
(frequency scaling, C-states and thermal management).
Tested on my venerable Toshiba Portege R500.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
2013-05-02 22:26:22 +00:00
|
|
|
|
2015-05-11 04:17:16 +00:00
|
|
|
pr->id = acpi_map_cpuid(pr->phys_id, pr->acpi_id);
|
2014-07-18 10:02:53 +00:00
|
|
|
if (!cpu0_initialized && !acpi_has_cpu_in_madt()) {
|
2014-01-09 08:15:19 +00:00
|
|
|
cpu0_initialized = 1;
|
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 <hanjun.guo@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-04 10:55:02 +00:00
|
|
|
/*
|
|
|
|
* Handle UP system running SMP kernel, with no CPU
|
|
|
|
* entry in MADT
|
|
|
|
*/
|
2015-05-11 04:17:16 +00:00
|
|
|
if (invalid_logical_cpuid(pr->id) && (num_online_cpus() == 1))
|
|
|
|
pr->id = 0;
|
2014-01-09 08:15:19 +00:00
|
|
|
}
|
ACPI / processor: Use common hotplug infrastructure
Split the ACPI processor driver into two parts, one that is
non-modular, resides in the ACPI core and handles the enumeration
and hotplug of processors and one that implements the rest of the
existing processor driver functionality.
The non-modular part uses an ACPI scan handler object to enumerate
processors on the basis of information provided by the ACPI namespace
and to hook up with the common ACPI hotplug infrastructure. It also
populates the ACPI handle of each processor device having a
corresponding object in the ACPI namespace, which allows the driver
proper to bind to those devices, and makes the driver bind to them
if it is readily available (i.e. loaded) when the scan handler's
.attach() routine is running.
There are a few reasons to make this change.
First, switching the ACPI processor driver to using the common ACPI
hotplug infrastructure reduces code duplication and size considerably,
even though a new file is created along with a header comment etc.
Second, since the common hotplug code attempts to offline devices
before starting the (non-reversible) removal procedure, it will abort
(and possibly roll back) hot-remove operations involving processors
if cpu_down() returns an error code for one of them instead of
continuing them blindly (if /sys/firmware/acpi/hotplug/force_remove
is unset). That is a more desirable behavior than what the current
code does.
Finally, the separation of the scan/hotplug part from the driver
proper makes it possible to simplify the driver's .remove() routine,
because it doesn't need to worry about the possible cleanup related
to processor removal any more (the scan/hotplug part is responsible
for that now) and can handle device removal and driver removal
symmetricaly (i.e. as appropriate).
Some user-visible changes in sysfs are made (for example, the
'sysdev' link from the ACPI device node to the processor device's
directory is gone and a 'physical_node' link is present instead
and a corresponding 'firmware_node' is present in the processor
device's directory, the processor driver is now visible under
/sys/bus/cpu/drivers/ and bound to the processor device), but
that shouldn't affect the functionality that users care about
(frequency scaling, C-states and thermal management).
Tested on my venerable Toshiba Portege R500.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
2013-05-02 22:26:22 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Extra Processor objects may be enumerated on MP systems with
|
|
|
|
* less than the max # of CPUs. They should be ignored _iff
|
|
|
|
* they are physically not present.
|
2016-08-25 08:35:17 +00:00
|
|
|
*
|
|
|
|
* NOTE: Even if the processor has a cpuid, it may not be present
|
|
|
|
* because cpuid <-> apicid mapping is persistent now.
|
ACPI / processor: Use common hotplug infrastructure
Split the ACPI processor driver into two parts, one that is
non-modular, resides in the ACPI core and handles the enumeration
and hotplug of processors and one that implements the rest of the
existing processor driver functionality.
The non-modular part uses an ACPI scan handler object to enumerate
processors on the basis of information provided by the ACPI namespace
and to hook up with the common ACPI hotplug infrastructure. It also
populates the ACPI handle of each processor device having a
corresponding object in the ACPI namespace, which allows the driver
proper to bind to those devices, and makes the driver bind to them
if it is readily available (i.e. loaded) when the scan handler's
.attach() routine is running.
There are a few reasons to make this change.
First, switching the ACPI processor driver to using the common ACPI
hotplug infrastructure reduces code duplication and size considerably,
even though a new file is created along with a header comment etc.
Second, since the common hotplug code attempts to offline devices
before starting the (non-reversible) removal procedure, it will abort
(and possibly roll back) hot-remove operations involving processors
if cpu_down() returns an error code for one of them instead of
continuing them blindly (if /sys/firmware/acpi/hotplug/force_remove
is unset). That is a more desirable behavior than what the current
code does.
Finally, the separation of the scan/hotplug part from the driver
proper makes it possible to simplify the driver's .remove() routine,
because it doesn't need to worry about the possible cleanup related
to processor removal any more (the scan/hotplug part is responsible
for that now) and can handle device removal and driver removal
symmetricaly (i.e. as appropriate).
Some user-visible changes in sysfs are made (for example, the
'sysdev' link from the ACPI device node to the processor device's
directory is gone and a 'physical_node' link is present instead
and a corresponding 'firmware_node' is present in the processor
device's directory, the processor driver is now visible under
/sys/bus/cpu/drivers/ and bound to the processor device), but
that shouldn't affect the functionality that users care about
(frequency scaling, C-states and thermal management).
Tested on my venerable Toshiba Portege R500.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
2013-05-02 22:26:22 +00:00
|
|
|
*/
|
2016-08-25 08:35:17 +00:00
|
|
|
if (invalid_logical_cpuid(pr->id) || !cpu_present(pr->id)) {
|
ACPI / processor: Use common hotplug infrastructure
Split the ACPI processor driver into two parts, one that is
non-modular, resides in the ACPI core and handles the enumeration
and hotplug of processors and one that implements the rest of the
existing processor driver functionality.
The non-modular part uses an ACPI scan handler object to enumerate
processors on the basis of information provided by the ACPI namespace
and to hook up with the common ACPI hotplug infrastructure. It also
populates the ACPI handle of each processor device having a
corresponding object in the ACPI namespace, which allows the driver
proper to bind to those devices, and makes the driver bind to them
if it is readily available (i.e. loaded) when the scan handler's
.attach() routine is running.
There are a few reasons to make this change.
First, switching the ACPI processor driver to using the common ACPI
hotplug infrastructure reduces code duplication and size considerably,
even though a new file is created along with a header comment etc.
Second, since the common hotplug code attempts to offline devices
before starting the (non-reversible) removal procedure, it will abort
(and possibly roll back) hot-remove operations involving processors
if cpu_down() returns an error code for one of them instead of
continuing them blindly (if /sys/firmware/acpi/hotplug/force_remove
is unset). That is a more desirable behavior than what the current
code does.
Finally, the separation of the scan/hotplug part from the driver
proper makes it possible to simplify the driver's .remove() routine,
because it doesn't need to worry about the possible cleanup related
to processor removal any more (the scan/hotplug part is responsible
for that now) and can handle device removal and driver removal
symmetricaly (i.e. as appropriate).
Some user-visible changes in sysfs are made (for example, the
'sysdev' link from the ACPI device node to the processor device's
directory is gone and a 'physical_node' link is present instead
and a corresponding 'firmware_node' is present in the processor
device's directory, the processor driver is now visible under
/sys/bus/cpu/drivers/ and bound to the processor device), but
that shouldn't affect the functionality that users care about
(frequency scaling, C-states and thermal management).
Tested on my venerable Toshiba Portege R500.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
2013-05-02 22:26:22 +00:00
|
|
|
int ret = acpi_processor_hotadd_init(pr);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
2014-01-09 08:15:19 +00:00
|
|
|
|
ACPI / processor: Use common hotplug infrastructure
Split the ACPI processor driver into two parts, one that is
non-modular, resides in the ACPI core and handles the enumeration
and hotplug of processors and one that implements the rest of the
existing processor driver functionality.
The non-modular part uses an ACPI scan handler object to enumerate
processors on the basis of information provided by the ACPI namespace
and to hook up with the common ACPI hotplug infrastructure. It also
populates the ACPI handle of each processor device having a
corresponding object in the ACPI namespace, which allows the driver
proper to bind to those devices, and makes the driver bind to them
if it is readily available (i.e. loaded) when the scan handler's
.attach() routine is running.
There are a few reasons to make this change.
First, switching the ACPI processor driver to using the common ACPI
hotplug infrastructure reduces code duplication and size considerably,
even though a new file is created along with a header comment etc.
Second, since the common hotplug code attempts to offline devices
before starting the (non-reversible) removal procedure, it will abort
(and possibly roll back) hot-remove operations involving processors
if cpu_down() returns an error code for one of them instead of
continuing them blindly (if /sys/firmware/acpi/hotplug/force_remove
is unset). That is a more desirable behavior than what the current
code does.
Finally, the separation of the scan/hotplug part from the driver
proper makes it possible to simplify the driver's .remove() routine,
because it doesn't need to worry about the possible cleanup related
to processor removal any more (the scan/hotplug part is responsible
for that now) and can handle device removal and driver removal
symmetricaly (i.e. as appropriate).
Some user-visible changes in sysfs are made (for example, the
'sysdev' link from the ACPI device node to the processor device's
directory is gone and a 'physical_node' link is present instead
and a corresponding 'firmware_node' is present in the processor
device's directory, the processor driver is now visible under
/sys/bus/cpu/drivers/ and bound to the processor device), but
that shouldn't affect the functionality that users care about
(frequency scaling, C-states and thermal management).
Tested on my venerable Toshiba Portege R500.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
2013-05-02 22:26:22 +00:00
|
|
|
/*
|
|
|
|
* On some boxes several processors use the same processor bus id.
|
|
|
|
* But they are located in different scope. For example:
|
|
|
|
* \_SB.SCK0.CPU0
|
|
|
|
* \_SB.SCK1.CPU0
|
|
|
|
* Rename the processor device bus id. And the new bus id will be
|
|
|
|
* generated as the following format:
|
|
|
|
* CPU+CPU ID.
|
|
|
|
*/
|
|
|
|
sprintf(acpi_device_bid(device), "CPU%X", pr->id);
|
|
|
|
ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Processor [%d:%d]\n", pr->id,
|
|
|
|
pr->acpi_id));
|
|
|
|
|
|
|
|
if (!object.processor.pblk_address)
|
|
|
|
ACPI_DEBUG_PRINT((ACPI_DB_INFO, "No PBLK (NULL address)\n"));
|
|
|
|
else if (object.processor.pblk_length != 6)
|
|
|
|
dev_err(&device->dev, "Invalid PBLK length [%d]\n",
|
|
|
|
object.processor.pblk_length);
|
|
|
|
else {
|
|
|
|
pr->throttling.address = object.processor.pblk_address;
|
|
|
|
pr->throttling.duty_offset = acpi_gbl_FADT.duty_offset;
|
|
|
|
pr->throttling.duty_width = acpi_gbl_FADT.duty_width;
|
|
|
|
|
|
|
|
pr->pblk = object.processor.pblk_address;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If ACPI describes a slot number for this CPU, we can use it to
|
|
|
|
* ensure we get the right value in the "physical id" field
|
|
|
|
* of /proc/cpuinfo
|
|
|
|
*/
|
2013-09-03 00:32:09 +00:00
|
|
|
status = acpi_evaluate_integer(pr->handle, "_SUN", NULL, &value);
|
ACPI / processor: Use common hotplug infrastructure
Split the ACPI processor driver into two parts, one that is
non-modular, resides in the ACPI core and handles the enumeration
and hotplug of processors and one that implements the rest of the
existing processor driver functionality.
The non-modular part uses an ACPI scan handler object to enumerate
processors on the basis of information provided by the ACPI namespace
and to hook up with the common ACPI hotplug infrastructure. It also
populates the ACPI handle of each processor device having a
corresponding object in the ACPI namespace, which allows the driver
proper to bind to those devices, and makes the driver bind to them
if it is readily available (i.e. loaded) when the scan handler's
.attach() routine is running.
There are a few reasons to make this change.
First, switching the ACPI processor driver to using the common ACPI
hotplug infrastructure reduces code duplication and size considerably,
even though a new file is created along with a header comment etc.
Second, since the common hotplug code attempts to offline devices
before starting the (non-reversible) removal procedure, it will abort
(and possibly roll back) hot-remove operations involving processors
if cpu_down() returns an error code for one of them instead of
continuing them blindly (if /sys/firmware/acpi/hotplug/force_remove
is unset). That is a more desirable behavior than what the current
code does.
Finally, the separation of the scan/hotplug part from the driver
proper makes it possible to simplify the driver's .remove() routine,
because it doesn't need to worry about the possible cleanup related
to processor removal any more (the scan/hotplug part is responsible
for that now) and can handle device removal and driver removal
symmetricaly (i.e. as appropriate).
Some user-visible changes in sysfs are made (for example, the
'sysdev' link from the ACPI device node to the processor device's
directory is gone and a 'physical_node' link is present instead
and a corresponding 'firmware_node' is present in the processor
device's directory, the processor driver is now visible under
/sys/bus/cpu/drivers/ and bound to the processor device), but
that shouldn't affect the functionality that users care about
(frequency scaling, C-states and thermal management).
Tested on my venerable Toshiba Portege R500.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
2013-05-02 22:26:22 +00:00
|
|
|
if (ACPI_SUCCESS(status))
|
2013-09-03 00:32:09 +00:00
|
|
|
arch_fix_phys_package_id(pr->id, value);
|
ACPI / processor: Use common hotplug infrastructure
Split the ACPI processor driver into two parts, one that is
non-modular, resides in the ACPI core and handles the enumeration
and hotplug of processors and one that implements the rest of the
existing processor driver functionality.
The non-modular part uses an ACPI scan handler object to enumerate
processors on the basis of information provided by the ACPI namespace
and to hook up with the common ACPI hotplug infrastructure. It also
populates the ACPI handle of each processor device having a
corresponding object in the ACPI namespace, which allows the driver
proper to bind to those devices, and makes the driver bind to them
if it is readily available (i.e. loaded) when the scan handler's
.attach() routine is running.
There are a few reasons to make this change.
First, switching the ACPI processor driver to using the common ACPI
hotplug infrastructure reduces code duplication and size considerably,
even though a new file is created along with a header comment etc.
Second, since the common hotplug code attempts to offline devices
before starting the (non-reversible) removal procedure, it will abort
(and possibly roll back) hot-remove operations involving processors
if cpu_down() returns an error code for one of them instead of
continuing them blindly (if /sys/firmware/acpi/hotplug/force_remove
is unset). That is a more desirable behavior than what the current
code does.
Finally, the separation of the scan/hotplug part from the driver
proper makes it possible to simplify the driver's .remove() routine,
because it doesn't need to worry about the possible cleanup related
to processor removal any more (the scan/hotplug part is responsible
for that now) and can handle device removal and driver removal
symmetricaly (i.e. as appropriate).
Some user-visible changes in sysfs are made (for example, the
'sysdev' link from the ACPI device node to the processor device's
directory is gone and a 'physical_node' link is present instead
and a corresponding 'firmware_node' is present in the processor
device's directory, the processor driver is now visible under
/sys/bus/cpu/drivers/ and bound to the processor device), but
that shouldn't affect the functionality that users care about
(frequency scaling, C-states and thermal management).
Tested on my venerable Toshiba Portege R500.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
2013-05-02 22:26:22 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Do not put anything in here which needs the core to be online.
|
|
|
|
* For example MSR access or setting up things which check for cpuinfo_x86
|
|
|
|
* (cpu_data(cpu)) values, like CPU feature flags, family, model, etc.
|
|
|
|
* Such things have to be put in and set up by the processor driver's .probe().
|
|
|
|
*/
|
|
|
|
static DEFINE_PER_CPU(void *, processor_device_array);
|
|
|
|
|
2013-06-19 18:30:58 +00:00
|
|
|
static int acpi_processor_add(struct acpi_device *device,
|
ACPI / processor: Use common hotplug infrastructure
Split the ACPI processor driver into two parts, one that is
non-modular, resides in the ACPI core and handles the enumeration
and hotplug of processors and one that implements the rest of the
existing processor driver functionality.
The non-modular part uses an ACPI scan handler object to enumerate
processors on the basis of information provided by the ACPI namespace
and to hook up with the common ACPI hotplug infrastructure. It also
populates the ACPI handle of each processor device having a
corresponding object in the ACPI namespace, which allows the driver
proper to bind to those devices, and makes the driver bind to them
if it is readily available (i.e. loaded) when the scan handler's
.attach() routine is running.
There are a few reasons to make this change.
First, switching the ACPI processor driver to using the common ACPI
hotplug infrastructure reduces code duplication and size considerably,
even though a new file is created along with a header comment etc.
Second, since the common hotplug code attempts to offline devices
before starting the (non-reversible) removal procedure, it will abort
(and possibly roll back) hot-remove operations involving processors
if cpu_down() returns an error code for one of them instead of
continuing them blindly (if /sys/firmware/acpi/hotplug/force_remove
is unset). That is a more desirable behavior than what the current
code does.
Finally, the separation of the scan/hotplug part from the driver
proper makes it possible to simplify the driver's .remove() routine,
because it doesn't need to worry about the possible cleanup related
to processor removal any more (the scan/hotplug part is responsible
for that now) and can handle device removal and driver removal
symmetricaly (i.e. as appropriate).
Some user-visible changes in sysfs are made (for example, the
'sysdev' link from the ACPI device node to the processor device's
directory is gone and a 'physical_node' link is present instead
and a corresponding 'firmware_node' is present in the processor
device's directory, the processor driver is now visible under
/sys/bus/cpu/drivers/ and bound to the processor device), but
that shouldn't affect the functionality that users care about
(frequency scaling, C-states and thermal management).
Tested on my venerable Toshiba Portege R500.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
2013-05-02 22:26:22 +00:00
|
|
|
const struct acpi_device_id *id)
|
|
|
|
{
|
|
|
|
struct acpi_processor *pr;
|
|
|
|
struct device *dev;
|
|
|
|
int result = 0;
|
|
|
|
|
|
|
|
pr = kzalloc(sizeof(struct acpi_processor), GFP_KERNEL);
|
|
|
|
if (!pr)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
if (!zalloc_cpumask_var(&pr->throttling.shared_cpu_map, GFP_KERNEL)) {
|
|
|
|
result = -ENOMEM;
|
|
|
|
goto err_free_pr;
|
|
|
|
}
|
|
|
|
|
|
|
|
pr->handle = device->handle;
|
|
|
|
strcpy(acpi_device_name(device), ACPI_PROCESSOR_DEVICE_NAME);
|
|
|
|
strcpy(acpi_device_class(device), ACPI_PROCESSOR_CLASS);
|
|
|
|
device->driver_data = pr;
|
|
|
|
|
|
|
|
result = acpi_processor_get_info(device);
|
|
|
|
if (result) /* Processor is not physically present or unavailable */
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
BUG_ON(pr->id >= nr_cpu_ids);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Buggy BIOS check.
|
|
|
|
* ACPI id of processors can be reported wrongly by the BIOS.
|
|
|
|
* Don't trust it blindly
|
|
|
|
*/
|
|
|
|
if (per_cpu(processor_device_array, pr->id) != NULL &&
|
|
|
|
per_cpu(processor_device_array, pr->id) != device) {
|
|
|
|
dev_warn(&device->dev,
|
|
|
|
"BIOS reported wrong ACPI id %d for the processor\n",
|
|
|
|
pr->id);
|
|
|
|
/* Give up, but do not abort the namespace scan. */
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
/*
|
|
|
|
* processor_device_array is not cleared on errors to allow buggy BIOS
|
|
|
|
* checks.
|
|
|
|
*/
|
|
|
|
per_cpu(processor_device_array, pr->id) = device;
|
2013-05-30 19:55:46 +00:00
|
|
|
per_cpu(processors, pr->id) = pr;
|
ACPI / processor: Use common hotplug infrastructure
Split the ACPI processor driver into two parts, one that is
non-modular, resides in the ACPI core and handles the enumeration
and hotplug of processors and one that implements the rest of the
existing processor driver functionality.
The non-modular part uses an ACPI scan handler object to enumerate
processors on the basis of information provided by the ACPI namespace
and to hook up with the common ACPI hotplug infrastructure. It also
populates the ACPI handle of each processor device having a
corresponding object in the ACPI namespace, which allows the driver
proper to bind to those devices, and makes the driver bind to them
if it is readily available (i.e. loaded) when the scan handler's
.attach() routine is running.
There are a few reasons to make this change.
First, switching the ACPI processor driver to using the common ACPI
hotplug infrastructure reduces code duplication and size considerably,
even though a new file is created along with a header comment etc.
Second, since the common hotplug code attempts to offline devices
before starting the (non-reversible) removal procedure, it will abort
(and possibly roll back) hot-remove operations involving processors
if cpu_down() returns an error code for one of them instead of
continuing them blindly (if /sys/firmware/acpi/hotplug/force_remove
is unset). That is a more desirable behavior than what the current
code does.
Finally, the separation of the scan/hotplug part from the driver
proper makes it possible to simplify the driver's .remove() routine,
because it doesn't need to worry about the possible cleanup related
to processor removal any more (the scan/hotplug part is responsible
for that now) and can handle device removal and driver removal
symmetricaly (i.e. as appropriate).
Some user-visible changes in sysfs are made (for example, the
'sysdev' link from the ACPI device node to the processor device's
directory is gone and a 'physical_node' link is present instead
and a corresponding 'firmware_node' is present in the processor
device's directory, the processor driver is now visible under
/sys/bus/cpu/drivers/ and bound to the processor device), but
that shouldn't affect the functionality that users care about
(frequency scaling, C-states and thermal management).
Tested on my venerable Toshiba Portege R500.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
2013-05-02 22:26:22 +00:00
|
|
|
|
|
|
|
dev = get_cpu_device(pr->id);
|
2013-05-31 03:36:08 +00:00
|
|
|
if (!dev) {
|
|
|
|
result = -ENODEV;
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
|
2013-11-29 15:27:43 +00:00
|
|
|
result = acpi_bind_one(dev, device);
|
ACPI / processor: Use common hotplug infrastructure
Split the ACPI processor driver into two parts, one that is
non-modular, resides in the ACPI core and handles the enumeration
and hotplug of processors and one that implements the rest of the
existing processor driver functionality.
The non-modular part uses an ACPI scan handler object to enumerate
processors on the basis of information provided by the ACPI namespace
and to hook up with the common ACPI hotplug infrastructure. It also
populates the ACPI handle of each processor device having a
corresponding object in the ACPI namespace, which allows the driver
proper to bind to those devices, and makes the driver bind to them
if it is readily available (i.e. loaded) when the scan handler's
.attach() routine is running.
There are a few reasons to make this change.
First, switching the ACPI processor driver to using the common ACPI
hotplug infrastructure reduces code duplication and size considerably,
even though a new file is created along with a header comment etc.
Second, since the common hotplug code attempts to offline devices
before starting the (non-reversible) removal procedure, it will abort
(and possibly roll back) hot-remove operations involving processors
if cpu_down() returns an error code for one of them instead of
continuing them blindly (if /sys/firmware/acpi/hotplug/force_remove
is unset). That is a more desirable behavior than what the current
code does.
Finally, the separation of the scan/hotplug part from the driver
proper makes it possible to simplify the driver's .remove() routine,
because it doesn't need to worry about the possible cleanup related
to processor removal any more (the scan/hotplug part is responsible
for that now) and can handle device removal and driver removal
symmetricaly (i.e. as appropriate).
Some user-visible changes in sysfs are made (for example, the
'sysdev' link from the ACPI device node to the processor device's
directory is gone and a 'physical_node' link is present instead
and a corresponding 'firmware_node' is present in the processor
device's directory, the processor driver is now visible under
/sys/bus/cpu/drivers/ and bound to the processor device), but
that shouldn't affect the functionality that users care about
(frequency scaling, C-states and thermal management).
Tested on my venerable Toshiba Portege R500.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
2013-05-02 22:26:22 +00:00
|
|
|
if (result)
|
|
|
|
goto err;
|
|
|
|
|
|
|
|
pr->dev = dev;
|
|
|
|
|
|
|
|
/* Trigger the processor driver's .probe() if present. */
|
|
|
|
if (device_attach(dev) >= 0)
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
dev_err(dev, "Processor driver could not be attached\n");
|
|
|
|
acpi_unbind_one(dev);
|
|
|
|
|
|
|
|
err:
|
|
|
|
free_cpumask_var(pr->throttling.shared_cpu_map);
|
|
|
|
device->driver_data = NULL;
|
2013-05-30 19:55:46 +00:00
|
|
|
per_cpu(processors, pr->id) = NULL;
|
ACPI / processor: Use common hotplug infrastructure
Split the ACPI processor driver into two parts, one that is
non-modular, resides in the ACPI core and handles the enumeration
and hotplug of processors and one that implements the rest of the
existing processor driver functionality.
The non-modular part uses an ACPI scan handler object to enumerate
processors on the basis of information provided by the ACPI namespace
and to hook up with the common ACPI hotplug infrastructure. It also
populates the ACPI handle of each processor device having a
corresponding object in the ACPI namespace, which allows the driver
proper to bind to those devices, and makes the driver bind to them
if it is readily available (i.e. loaded) when the scan handler's
.attach() routine is running.
There are a few reasons to make this change.
First, switching the ACPI processor driver to using the common ACPI
hotplug infrastructure reduces code duplication and size considerably,
even though a new file is created along with a header comment etc.
Second, since the common hotplug code attempts to offline devices
before starting the (non-reversible) removal procedure, it will abort
(and possibly roll back) hot-remove operations involving processors
if cpu_down() returns an error code for one of them instead of
continuing them blindly (if /sys/firmware/acpi/hotplug/force_remove
is unset). That is a more desirable behavior than what the current
code does.
Finally, the separation of the scan/hotplug part from the driver
proper makes it possible to simplify the driver's .remove() routine,
because it doesn't need to worry about the possible cleanup related
to processor removal any more (the scan/hotplug part is responsible
for that now) and can handle device removal and driver removal
symmetricaly (i.e. as appropriate).
Some user-visible changes in sysfs are made (for example, the
'sysdev' link from the ACPI device node to the processor device's
directory is gone and a 'physical_node' link is present instead
and a corresponding 'firmware_node' is present in the processor
device's directory, the processor driver is now visible under
/sys/bus/cpu/drivers/ and bound to the processor device), but
that shouldn't affect the functionality that users care about
(frequency scaling, C-states and thermal management).
Tested on my venerable Toshiba Portege R500.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
2013-05-02 22:26:22 +00:00
|
|
|
err_free_pr:
|
|
|
|
kfree(pr);
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef CONFIG_ACPI_HOTPLUG_CPU
|
|
|
|
/* --------------------------------------------------------------------------
|
|
|
|
Removal
|
|
|
|
-------------------------------------------------------------------------- */
|
|
|
|
|
|
|
|
static void acpi_processor_remove(struct acpi_device *device)
|
|
|
|
{
|
|
|
|
struct acpi_processor *pr;
|
|
|
|
|
|
|
|
if (!device || !acpi_driver_data(device))
|
|
|
|
return;
|
|
|
|
|
|
|
|
pr = acpi_driver_data(device);
|
|
|
|
if (pr->id >= nr_cpu_ids)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The only reason why we ever get here is CPU hot-removal. The CPU is
|
|
|
|
* already offline and the ACPI device removal locking prevents it from
|
|
|
|
* being put back online at this point.
|
|
|
|
*
|
|
|
|
* Unbind the driver from the processor device and detach it from the
|
|
|
|
* ACPI companion object.
|
|
|
|
*/
|
|
|
|
device_release_driver(pr->dev);
|
|
|
|
acpi_unbind_one(pr->dev);
|
|
|
|
|
|
|
|
/* Clean up. */
|
|
|
|
per_cpu(processor_device_array, pr->id) = NULL;
|
2013-05-30 19:55:46 +00:00
|
|
|
per_cpu(processors, pr->id) = NULL;
|
ACPI / processor: Use common hotplug infrastructure
Split the ACPI processor driver into two parts, one that is
non-modular, resides in the ACPI core and handles the enumeration
and hotplug of processors and one that implements the rest of the
existing processor driver functionality.
The non-modular part uses an ACPI scan handler object to enumerate
processors on the basis of information provided by the ACPI namespace
and to hook up with the common ACPI hotplug infrastructure. It also
populates the ACPI handle of each processor device having a
corresponding object in the ACPI namespace, which allows the driver
proper to bind to those devices, and makes the driver bind to them
if it is readily available (i.e. loaded) when the scan handler's
.attach() routine is running.
There are a few reasons to make this change.
First, switching the ACPI processor driver to using the common ACPI
hotplug infrastructure reduces code duplication and size considerably,
even though a new file is created along with a header comment etc.
Second, since the common hotplug code attempts to offline devices
before starting the (non-reversible) removal procedure, it will abort
(and possibly roll back) hot-remove operations involving processors
if cpu_down() returns an error code for one of them instead of
continuing them blindly (if /sys/firmware/acpi/hotplug/force_remove
is unset). That is a more desirable behavior than what the current
code does.
Finally, the separation of the scan/hotplug part from the driver
proper makes it possible to simplify the driver's .remove() routine,
because it doesn't need to worry about the possible cleanup related
to processor removal any more (the scan/hotplug part is responsible
for that now) and can handle device removal and driver removal
symmetricaly (i.e. as appropriate).
Some user-visible changes in sysfs are made (for example, the
'sysdev' link from the ACPI device node to the processor device's
directory is gone and a 'physical_node' link is present instead
and a corresponding 'firmware_node' is present in the processor
device's directory, the processor driver is now visible under
/sys/bus/cpu/drivers/ and bound to the processor device), but
that shouldn't affect the functionality that users care about
(frequency scaling, C-states and thermal management).
Tested on my venerable Toshiba Portege R500.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
2013-05-02 22:26:22 +00:00
|
|
|
|
ACPI / processor: Acquire writer lock to update CPU maps
CPU system maps are protected with reader/writer locks. The reader
lock, get_online_cpus(), assures that the maps are not updated while
holding the lock. The writer lock, cpu_hotplug_begin(), is used to
udpate the cpu maps along with cpu_maps_update_begin().
However, the ACPI processor handler updates the cpu maps without
holding the the writer lock.
acpi_map_lsapic() is called from acpi_processor_hotadd_init() to
update cpu_possible_mask and cpu_present_mask. acpi_unmap_lsapic()
is called from acpi_processor_remove() to update cpu_possible_mask.
Currently, they are either unprotected or protected with the reader
lock, which is not correct.
For example, the get_online_cpus() below is supposed to assure that
cpu_possible_mask is not changed while the code is iterating with
for_each_possible_cpu().
get_online_cpus();
for_each_possible_cpu(cpu) {
:
}
put_online_cpus();
However, this lock has no protection with CPU hotplug since the ACPI
processor handler does not use the writer lock when it updates
cpu_possible_mask. The reader lock does not serialize within the
readers.
This patch protects them with the writer lock with cpu_hotplug_begin()
along with cpu_maps_update_begin(), which must be held before calling
cpu_hotplug_begin(). It also protects arch_register_cpu() /
arch_unregister_cpu(), which creates / deletes a sysfs cpu device
interface. For this purpose it changes cpu_hotplug_begin() and
cpu_hotplug_done() to global and exports them in cpu.h.
Signed-off-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-08-12 15:45:53 +00:00
|
|
|
cpu_maps_update_begin();
|
|
|
|
cpu_hotplug_begin();
|
|
|
|
|
ACPI / processor: Use common hotplug infrastructure
Split the ACPI processor driver into two parts, one that is
non-modular, resides in the ACPI core and handles the enumeration
and hotplug of processors and one that implements the rest of the
existing processor driver functionality.
The non-modular part uses an ACPI scan handler object to enumerate
processors on the basis of information provided by the ACPI namespace
and to hook up with the common ACPI hotplug infrastructure. It also
populates the ACPI handle of each processor device having a
corresponding object in the ACPI namespace, which allows the driver
proper to bind to those devices, and makes the driver bind to them
if it is readily available (i.e. loaded) when the scan handler's
.attach() routine is running.
There are a few reasons to make this change.
First, switching the ACPI processor driver to using the common ACPI
hotplug infrastructure reduces code duplication and size considerably,
even though a new file is created along with a header comment etc.
Second, since the common hotplug code attempts to offline devices
before starting the (non-reversible) removal procedure, it will abort
(and possibly roll back) hot-remove operations involving processors
if cpu_down() returns an error code for one of them instead of
continuing them blindly (if /sys/firmware/acpi/hotplug/force_remove
is unset). That is a more desirable behavior than what the current
code does.
Finally, the separation of the scan/hotplug part from the driver
proper makes it possible to simplify the driver's .remove() routine,
because it doesn't need to worry about the possible cleanup related
to processor removal any more (the scan/hotplug part is responsible
for that now) and can handle device removal and driver removal
symmetricaly (i.e. as appropriate).
Some user-visible changes in sysfs are made (for example, the
'sysdev' link from the ACPI device node to the processor device's
directory is gone and a 'physical_node' link is present instead
and a corresponding 'firmware_node' is present in the processor
device's directory, the processor driver is now visible under
/sys/bus/cpu/drivers/ and bound to the processor device), but
that shouldn't affect the functionality that users care about
(frequency scaling, C-states and thermal management).
Tested on my venerable Toshiba Portege R500.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
2013-05-02 22:26:22 +00:00
|
|
|
/* Remove the CPU. */
|
|
|
|
arch_unregister_cpu(pr->id);
|
2015-01-04 10:55:03 +00:00
|
|
|
acpi_unmap_cpu(pr->id);
|
ACPI / processor: Acquire writer lock to update CPU maps
CPU system maps are protected with reader/writer locks. The reader
lock, get_online_cpus(), assures that the maps are not updated while
holding the lock. The writer lock, cpu_hotplug_begin(), is used to
udpate the cpu maps along with cpu_maps_update_begin().
However, the ACPI processor handler updates the cpu maps without
holding the the writer lock.
acpi_map_lsapic() is called from acpi_processor_hotadd_init() to
update cpu_possible_mask and cpu_present_mask. acpi_unmap_lsapic()
is called from acpi_processor_remove() to update cpu_possible_mask.
Currently, they are either unprotected or protected with the reader
lock, which is not correct.
For example, the get_online_cpus() below is supposed to assure that
cpu_possible_mask is not changed while the code is iterating with
for_each_possible_cpu().
get_online_cpus();
for_each_possible_cpu(cpu) {
:
}
put_online_cpus();
However, this lock has no protection with CPU hotplug since the ACPI
processor handler does not use the writer lock when it updates
cpu_possible_mask. The reader lock does not serialize within the
readers.
This patch protects them with the writer lock with cpu_hotplug_begin()
along with cpu_maps_update_begin(), which must be held before calling
cpu_hotplug_begin(). It also protects arch_register_cpu() /
arch_unregister_cpu(), which creates / deletes a sysfs cpu device
interface. For this purpose it changes cpu_hotplug_begin() and
cpu_hotplug_done() to global and exports them in cpu.h.
Signed-off-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-08-12 15:45:53 +00:00
|
|
|
|
|
|
|
cpu_hotplug_done();
|
|
|
|
cpu_maps_update_done();
|
ACPI / processor: Use common hotplug infrastructure
Split the ACPI processor driver into two parts, one that is
non-modular, resides in the ACPI core and handles the enumeration
and hotplug of processors and one that implements the rest of the
existing processor driver functionality.
The non-modular part uses an ACPI scan handler object to enumerate
processors on the basis of information provided by the ACPI namespace
and to hook up with the common ACPI hotplug infrastructure. It also
populates the ACPI handle of each processor device having a
corresponding object in the ACPI namespace, which allows the driver
proper to bind to those devices, and makes the driver bind to them
if it is readily available (i.e. loaded) when the scan handler's
.attach() routine is running.
There are a few reasons to make this change.
First, switching the ACPI processor driver to using the common ACPI
hotplug infrastructure reduces code duplication and size considerably,
even though a new file is created along with a header comment etc.
Second, since the common hotplug code attempts to offline devices
before starting the (non-reversible) removal procedure, it will abort
(and possibly roll back) hot-remove operations involving processors
if cpu_down() returns an error code for one of them instead of
continuing them blindly (if /sys/firmware/acpi/hotplug/force_remove
is unset). That is a more desirable behavior than what the current
code does.
Finally, the separation of the scan/hotplug part from the driver
proper makes it possible to simplify the driver's .remove() routine,
because it doesn't need to worry about the possible cleanup related
to processor removal any more (the scan/hotplug part is responsible
for that now) and can handle device removal and driver removal
symmetricaly (i.e. as appropriate).
Some user-visible changes in sysfs are made (for example, the
'sysdev' link from the ACPI device node to the processor device's
directory is gone and a 'physical_node' link is present instead
and a corresponding 'firmware_node' is present in the processor
device's directory, the processor driver is now visible under
/sys/bus/cpu/drivers/ and bound to the processor device), but
that shouldn't affect the functionality that users care about
(frequency scaling, C-states and thermal management).
Tested on my venerable Toshiba Portege R500.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
2013-05-02 22:26:22 +00:00
|
|
|
|
2013-08-06 10:11:11 +00:00
|
|
|
try_offline_node(cpu_to_node(pr->id));
|
|
|
|
|
ACPI / processor: Use common hotplug infrastructure
Split the ACPI processor driver into two parts, one that is
non-modular, resides in the ACPI core and handles the enumeration
and hotplug of processors and one that implements the rest of the
existing processor driver functionality.
The non-modular part uses an ACPI scan handler object to enumerate
processors on the basis of information provided by the ACPI namespace
and to hook up with the common ACPI hotplug infrastructure. It also
populates the ACPI handle of each processor device having a
corresponding object in the ACPI namespace, which allows the driver
proper to bind to those devices, and makes the driver bind to them
if it is readily available (i.e. loaded) when the scan handler's
.attach() routine is running.
There are a few reasons to make this change.
First, switching the ACPI processor driver to using the common ACPI
hotplug infrastructure reduces code duplication and size considerably,
even though a new file is created along with a header comment etc.
Second, since the common hotplug code attempts to offline devices
before starting the (non-reversible) removal procedure, it will abort
(and possibly roll back) hot-remove operations involving processors
if cpu_down() returns an error code for one of them instead of
continuing them blindly (if /sys/firmware/acpi/hotplug/force_remove
is unset). That is a more desirable behavior than what the current
code does.
Finally, the separation of the scan/hotplug part from the driver
proper makes it possible to simplify the driver's .remove() routine,
because it doesn't need to worry about the possible cleanup related
to processor removal any more (the scan/hotplug part is responsible
for that now) and can handle device removal and driver removal
symmetricaly (i.e. as appropriate).
Some user-visible changes in sysfs are made (for example, the
'sysdev' link from the ACPI device node to the processor device's
directory is gone and a 'physical_node' link is present instead
and a corresponding 'firmware_node' is present in the processor
device's directory, the processor driver is now visible under
/sys/bus/cpu/drivers/ and bound to the processor device), but
that shouldn't affect the functionality that users care about
(frequency scaling, C-states and thermal management).
Tested on my venerable Toshiba Portege R500.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
2013-05-02 22:26:22 +00:00
|
|
|
out:
|
|
|
|
free_cpumask_var(pr->throttling.shared_cpu_map);
|
|
|
|
kfree(pr);
|
|
|
|
}
|
|
|
|
#endif /* CONFIG_ACPI_HOTPLUG_CPU */
|
|
|
|
|
2016-03-24 04:07:39 +00:00
|
|
|
#ifdef CONFIG_X86
|
|
|
|
static bool acpi_hwp_native_thermal_lvt_set;
|
|
|
|
static acpi_status __init acpi_hwp_native_thermal_lvt_osc(acpi_handle handle,
|
|
|
|
u32 lvl,
|
|
|
|
void *context,
|
|
|
|
void **rv)
|
|
|
|
{
|
|
|
|
u8 sb_uuid_str[] = "4077A616-290C-47BE-9EBD-D87058713953";
|
|
|
|
u32 capbuf[2];
|
|
|
|
struct acpi_osc_context osc_context = {
|
|
|
|
.uuid_str = sb_uuid_str,
|
|
|
|
.rev = 1,
|
|
|
|
.cap.length = 8,
|
|
|
|
.cap.pointer = capbuf,
|
|
|
|
};
|
|
|
|
|
|
|
|
if (acpi_hwp_native_thermal_lvt_set)
|
|
|
|
return AE_CTRL_TERMINATE;
|
|
|
|
|
|
|
|
capbuf[0] = 0x0000;
|
|
|
|
capbuf[1] = 0x1000; /* set bit 12 */
|
|
|
|
|
|
|
|
if (ACPI_SUCCESS(acpi_run_osc(handle, &osc_context))) {
|
|
|
|
if (osc_context.ret.pointer && osc_context.ret.length > 1) {
|
|
|
|
u32 *capbuf_ret = osc_context.ret.pointer;
|
|
|
|
|
|
|
|
if (capbuf_ret[1] & 0x1000) {
|
|
|
|
acpi_handle_info(handle,
|
|
|
|
"_OSC native thermal LVT Acked\n");
|
|
|
|
acpi_hwp_native_thermal_lvt_set = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
kfree(osc_context.ret.pointer);
|
|
|
|
}
|
|
|
|
|
|
|
|
return AE_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
void __init acpi_early_processor_osc(void)
|
|
|
|
{
|
|
|
|
if (boot_cpu_has(X86_FEATURE_HWP)) {
|
|
|
|
acpi_walk_namespace(ACPI_TYPE_PROCESSOR, ACPI_ROOT_OBJECT,
|
|
|
|
ACPI_UINT32_MAX,
|
|
|
|
acpi_hwp_native_thermal_lvt_osc,
|
|
|
|
NULL, NULL, NULL);
|
|
|
|
acpi_get_devices(ACPI_PROCESSOR_DEVICE_HID,
|
|
|
|
acpi_hwp_native_thermal_lvt_osc,
|
|
|
|
NULL, NULL);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
ACPI / processor: Use common hotplug infrastructure
Split the ACPI processor driver into two parts, one that is
non-modular, resides in the ACPI core and handles the enumeration
and hotplug of processors and one that implements the rest of the
existing processor driver functionality.
The non-modular part uses an ACPI scan handler object to enumerate
processors on the basis of information provided by the ACPI namespace
and to hook up with the common ACPI hotplug infrastructure. It also
populates the ACPI handle of each processor device having a
corresponding object in the ACPI namespace, which allows the driver
proper to bind to those devices, and makes the driver bind to them
if it is readily available (i.e. loaded) when the scan handler's
.attach() routine is running.
There are a few reasons to make this change.
First, switching the ACPI processor driver to using the common ACPI
hotplug infrastructure reduces code duplication and size considerably,
even though a new file is created along with a header comment etc.
Second, since the common hotplug code attempts to offline devices
before starting the (non-reversible) removal procedure, it will abort
(and possibly roll back) hot-remove operations involving processors
if cpu_down() returns an error code for one of them instead of
continuing them blindly (if /sys/firmware/acpi/hotplug/force_remove
is unset). That is a more desirable behavior than what the current
code does.
Finally, the separation of the scan/hotplug part from the driver
proper makes it possible to simplify the driver's .remove() routine,
because it doesn't need to worry about the possible cleanup related
to processor removal any more (the scan/hotplug part is responsible
for that now) and can handle device removal and driver removal
symmetricaly (i.e. as appropriate).
Some user-visible changes in sysfs are made (for example, the
'sysdev' link from the ACPI device node to the processor device's
directory is gone and a 'physical_node' link is present instead
and a corresponding 'firmware_node' is present in the processor
device's directory, the processor driver is now visible under
/sys/bus/cpu/drivers/ and bound to the processor device), but
that shouldn't affect the functionality that users care about
(frequency scaling, C-states and thermal management).
Tested on my venerable Toshiba Portege R500.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
2013-05-02 22:26:22 +00:00
|
|
|
/*
|
|
|
|
* The following ACPI IDs are known to be suitable for representing as
|
|
|
|
* processor devices.
|
|
|
|
*/
|
|
|
|
static const struct acpi_device_id processor_device_ids[] = {
|
|
|
|
|
|
|
|
{ ACPI_PROCESSOR_OBJECT_HID, },
|
|
|
|
{ ACPI_PROCESSOR_DEVICE_HID, },
|
|
|
|
|
|
|
|
{ }
|
|
|
|
};
|
|
|
|
|
2015-07-19 16:50:38 +00:00
|
|
|
static struct acpi_scan_handler processor_handler = {
|
ACPI / processor: Use common hotplug infrastructure
Split the ACPI processor driver into two parts, one that is
non-modular, resides in the ACPI core and handles the enumeration
and hotplug of processors and one that implements the rest of the
existing processor driver functionality.
The non-modular part uses an ACPI scan handler object to enumerate
processors on the basis of information provided by the ACPI namespace
and to hook up with the common ACPI hotplug infrastructure. It also
populates the ACPI handle of each processor device having a
corresponding object in the ACPI namespace, which allows the driver
proper to bind to those devices, and makes the driver bind to them
if it is readily available (i.e. loaded) when the scan handler's
.attach() routine is running.
There are a few reasons to make this change.
First, switching the ACPI processor driver to using the common ACPI
hotplug infrastructure reduces code duplication and size considerably,
even though a new file is created along with a header comment etc.
Second, since the common hotplug code attempts to offline devices
before starting the (non-reversible) removal procedure, it will abort
(and possibly roll back) hot-remove operations involving processors
if cpu_down() returns an error code for one of them instead of
continuing them blindly (if /sys/firmware/acpi/hotplug/force_remove
is unset). That is a more desirable behavior than what the current
code does.
Finally, the separation of the scan/hotplug part from the driver
proper makes it possible to simplify the driver's .remove() routine,
because it doesn't need to worry about the possible cleanup related
to processor removal any more (the scan/hotplug part is responsible
for that now) and can handle device removal and driver removal
symmetricaly (i.e. as appropriate).
Some user-visible changes in sysfs are made (for example, the
'sysdev' link from the ACPI device node to the processor device's
directory is gone and a 'physical_node' link is present instead
and a corresponding 'firmware_node' is present in the processor
device's directory, the processor driver is now visible under
/sys/bus/cpu/drivers/ and bound to the processor device), but
that shouldn't affect the functionality that users care about
(frequency scaling, C-states and thermal management).
Tested on my venerable Toshiba Portege R500.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
2013-05-02 22:26:22 +00:00
|
|
|
.ids = processor_device_ids,
|
|
|
|
.attach = acpi_processor_add,
|
|
|
|
#ifdef CONFIG_ACPI_HOTPLUG_CPU
|
|
|
|
.detach = acpi_processor_remove,
|
|
|
|
#endif
|
|
|
|
.hotplug = {
|
|
|
|
.enabled = true,
|
|
|
|
},
|
|
|
|
};
|
|
|
|
|
2016-02-17 11:54:19 +00:00
|
|
|
static int acpi_processor_container_attach(struct acpi_device *dev,
|
|
|
|
const struct acpi_device_id *id)
|
|
|
|
{
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const struct acpi_device_id processor_container_ids[] = {
|
|
|
|
{ ACPI_PROCESSOR_CONTAINER_HID, },
|
|
|
|
{ }
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct acpi_scan_handler processor_container_handler = {
|
|
|
|
.ids = processor_container_ids,
|
|
|
|
.attach = acpi_processor_container_attach,
|
|
|
|
};
|
|
|
|
|
2016-08-25 08:35:19 +00:00
|
|
|
/* The number of the unique processor IDs */
|
|
|
|
static int nr_unique_ids __initdata;
|
|
|
|
|
|
|
|
/* The number of the duplicate processor IDs */
|
2017-03-03 08:02:27 +00:00
|
|
|
static int nr_duplicate_ids;
|
2016-08-25 08:35:19 +00:00
|
|
|
|
|
|
|
/* Used to store the unique processor IDs */
|
|
|
|
static int unique_processor_ids[] __initdata = {
|
|
|
|
[0 ... NR_CPUS - 1] = -1,
|
|
|
|
};
|
|
|
|
|
|
|
|
/* Used to store the duplicate processor IDs */
|
2017-03-03 08:02:27 +00:00
|
|
|
static int duplicate_processor_ids[] = {
|
2016-08-25 08:35:19 +00:00
|
|
|
[0 ... NR_CPUS - 1] = -1,
|
|
|
|
};
|
|
|
|
|
|
|
|
static void __init processor_validated_ids_update(int proc_id)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if (nr_unique_ids == NR_CPUS||nr_duplicate_ids == NR_CPUS)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Firstly, compare the proc_id with duplicate IDs, if the proc_id is
|
|
|
|
* already in the IDs, do nothing.
|
|
|
|
*/
|
|
|
|
for (i = 0; i < nr_duplicate_ids; i++) {
|
|
|
|
if (duplicate_processor_ids[i] == proc_id)
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Secondly, compare the proc_id with unique IDs, if the proc_id is in
|
|
|
|
* the IDs, put it in the duplicate IDs.
|
|
|
|
*/
|
|
|
|
for (i = 0; i < nr_unique_ids; i++) {
|
|
|
|
if (unique_processor_ids[i] == proc_id) {
|
|
|
|
duplicate_processor_ids[nr_duplicate_ids] = proc_id;
|
|
|
|
nr_duplicate_ids++;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Lastly, the proc_id is a unique ID, put it in the unique IDs.
|
|
|
|
*/
|
|
|
|
unique_processor_ids[nr_unique_ids] = proc_id;
|
|
|
|
nr_unique_ids++;
|
|
|
|
}
|
|
|
|
|
|
|
|
static acpi_status __init acpi_processor_ids_walk(acpi_handle handle,
|
|
|
|
u32 lvl,
|
|
|
|
void *context,
|
|
|
|
void **rv)
|
|
|
|
{
|
|
|
|
acpi_status status;
|
2017-03-03 08:02:26 +00:00
|
|
|
acpi_object_type acpi_type;
|
|
|
|
unsigned long long uid;
|
2016-08-25 08:35:19 +00:00
|
|
|
union acpi_object object = { 0 };
|
|
|
|
struct acpi_buffer buffer = { sizeof(union acpi_object), &object };
|
|
|
|
|
2017-03-03 08:02:26 +00:00
|
|
|
status = acpi_get_type(handle, &acpi_type);
|
2016-08-25 08:35:19 +00:00
|
|
|
if (ACPI_FAILURE(status))
|
2018-08-24 02:51:26 +00:00
|
|
|
return status;
|
2017-03-03 08:02:26 +00:00
|
|
|
|
|
|
|
switch (acpi_type) {
|
|
|
|
case ACPI_TYPE_PROCESSOR:
|
|
|
|
status = acpi_evaluate_object(handle, NULL, NULL, &buffer);
|
|
|
|
if (ACPI_FAILURE(status))
|
|
|
|
goto err;
|
|
|
|
uid = object.processor.proc_id;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case ACPI_TYPE_DEVICE:
|
|
|
|
status = acpi_evaluate_integer(handle, "_UID", NULL, &uid);
|
|
|
|
if (ACPI_FAILURE(status))
|
|
|
|
goto err;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
|
|
|
|
processor_validated_ids_update(uid);
|
2018-08-24 02:51:26 +00:00
|
|
|
return AE_OK;
|
2017-03-03 08:02:26 +00:00
|
|
|
|
|
|
|
err:
|
2018-08-24 02:51:26 +00:00
|
|
|
/* Exit on error, but don't abort the namespace walk */
|
2017-03-03 08:02:26 +00:00
|
|
|
acpi_handle_info(handle, "Invalid processor object\n");
|
2018-08-24 02:51:26 +00:00
|
|
|
return AE_OK;
|
2016-08-25 08:35:19 +00:00
|
|
|
|
|
|
|
}
|
|
|
|
|
2017-08-15 09:46:30 +00:00
|
|
|
static void __init acpi_processor_check_duplicates(void)
|
2016-08-25 08:35:19 +00:00
|
|
|
{
|
2017-03-03 08:02:26 +00:00
|
|
|
/* check the correctness for all processors in ACPI namespace */
|
2016-08-25 08:35:19 +00:00
|
|
|
acpi_walk_namespace(ACPI_TYPE_PROCESSOR, ACPI_ROOT_OBJECT,
|
|
|
|
ACPI_UINT32_MAX,
|
|
|
|
acpi_processor_ids_walk,
|
|
|
|
NULL, NULL, NULL);
|
2017-03-03 08:02:26 +00:00
|
|
|
acpi_get_devices(ACPI_PROCESSOR_DEVICE_HID, acpi_processor_ids_walk,
|
|
|
|
NULL, NULL);
|
2016-08-25 08:35:19 +00:00
|
|
|
}
|
|
|
|
|
2017-03-03 08:02:27 +00:00
|
|
|
bool acpi_duplicate_processor_id(int proc_id)
|
2016-08-25 08:35:20 +00:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* compare the proc_id with duplicate IDs, if the proc_id is already
|
|
|
|
* in the duplicate IDs, return true, otherwise, return false.
|
|
|
|
*/
|
|
|
|
for (i = 0; i < nr_duplicate_ids; i++) {
|
|
|
|
if (duplicate_processor_ids[i] == proc_id)
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
ACPI / processor: Use common hotplug infrastructure
Split the ACPI processor driver into two parts, one that is
non-modular, resides in the ACPI core and handles the enumeration
and hotplug of processors and one that implements the rest of the
existing processor driver functionality.
The non-modular part uses an ACPI scan handler object to enumerate
processors on the basis of information provided by the ACPI namespace
and to hook up with the common ACPI hotplug infrastructure. It also
populates the ACPI handle of each processor device having a
corresponding object in the ACPI namespace, which allows the driver
proper to bind to those devices, and makes the driver bind to them
if it is readily available (i.e. loaded) when the scan handler's
.attach() routine is running.
There are a few reasons to make this change.
First, switching the ACPI processor driver to using the common ACPI
hotplug infrastructure reduces code duplication and size considerably,
even though a new file is created along with a header comment etc.
Second, since the common hotplug code attempts to offline devices
before starting the (non-reversible) removal procedure, it will abort
(and possibly roll back) hot-remove operations involving processors
if cpu_down() returns an error code for one of them instead of
continuing them blindly (if /sys/firmware/acpi/hotplug/force_remove
is unset). That is a more desirable behavior than what the current
code does.
Finally, the separation of the scan/hotplug part from the driver
proper makes it possible to simplify the driver's .remove() routine,
because it doesn't need to worry about the possible cleanup related
to processor removal any more (the scan/hotplug part is responsible
for that now) and can handle device removal and driver removal
symmetricaly (i.e. as appropriate).
Some user-visible changes in sysfs are made (for example, the
'sysdev' link from the ACPI device node to the processor device's
directory is gone and a 'physical_node' link is present instead
and a corresponding 'firmware_node' is present in the processor
device's directory, the processor driver is now visible under
/sys/bus/cpu/drivers/ and bound to the processor device), but
that shouldn't affect the functionality that users care about
(frequency scaling, C-states and thermal management).
Tested on my venerable Toshiba Portege R500.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
2013-05-02 22:26:22 +00:00
|
|
|
void __init acpi_processor_init(void)
|
|
|
|
{
|
2016-08-25 08:35:19 +00:00
|
|
|
acpi_processor_check_duplicates();
|
ACPI / processor: Use common hotplug infrastructure
Split the ACPI processor driver into two parts, one that is
non-modular, resides in the ACPI core and handles the enumeration
and hotplug of processors and one that implements the rest of the
existing processor driver functionality.
The non-modular part uses an ACPI scan handler object to enumerate
processors on the basis of information provided by the ACPI namespace
and to hook up with the common ACPI hotplug infrastructure. It also
populates the ACPI handle of each processor device having a
corresponding object in the ACPI namespace, which allows the driver
proper to bind to those devices, and makes the driver bind to them
if it is readily available (i.e. loaded) when the scan handler's
.attach() routine is running.
There are a few reasons to make this change.
First, switching the ACPI processor driver to using the common ACPI
hotplug infrastructure reduces code duplication and size considerably,
even though a new file is created along with a header comment etc.
Second, since the common hotplug code attempts to offline devices
before starting the (non-reversible) removal procedure, it will abort
(and possibly roll back) hot-remove operations involving processors
if cpu_down() returns an error code for one of them instead of
continuing them blindly (if /sys/firmware/acpi/hotplug/force_remove
is unset). That is a more desirable behavior than what the current
code does.
Finally, the separation of the scan/hotplug part from the driver
proper makes it possible to simplify the driver's .remove() routine,
because it doesn't need to worry about the possible cleanup related
to processor removal any more (the scan/hotplug part is responsible
for that now) and can handle device removal and driver removal
symmetricaly (i.e. as appropriate).
Some user-visible changes in sysfs are made (for example, the
'sysdev' link from the ACPI device node to the processor device's
directory is gone and a 'physical_node' link is present instead
and a corresponding 'firmware_node' is present in the processor
device's directory, the processor driver is now visible under
/sys/bus/cpu/drivers/ and bound to the processor device), but
that shouldn't affect the functionality that users care about
(frequency scaling, C-states and thermal management).
Tested on my venerable Toshiba Portege R500.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
2013-05-02 22:26:22 +00:00
|
|
|
acpi_scan_add_handler_with_hotplug(&processor_handler, "processor");
|
2016-02-17 11:54:19 +00:00
|
|
|
acpi_scan_add_handler(&processor_container_handler);
|
ACPI / processor: Use common hotplug infrastructure
Split the ACPI processor driver into two parts, one that is
non-modular, resides in the ACPI core and handles the enumeration
and hotplug of processors and one that implements the rest of the
existing processor driver functionality.
The non-modular part uses an ACPI scan handler object to enumerate
processors on the basis of information provided by the ACPI namespace
and to hook up with the common ACPI hotplug infrastructure. It also
populates the ACPI handle of each processor device having a
corresponding object in the ACPI namespace, which allows the driver
proper to bind to those devices, and makes the driver bind to them
if it is readily available (i.e. loaded) when the scan handler's
.attach() routine is running.
There are a few reasons to make this change.
First, switching the ACPI processor driver to using the common ACPI
hotplug infrastructure reduces code duplication and size considerably,
even though a new file is created along with a header comment etc.
Second, since the common hotplug code attempts to offline devices
before starting the (non-reversible) removal procedure, it will abort
(and possibly roll back) hot-remove operations involving processors
if cpu_down() returns an error code for one of them instead of
continuing them blindly (if /sys/firmware/acpi/hotplug/force_remove
is unset). That is a more desirable behavior than what the current
code does.
Finally, the separation of the scan/hotplug part from the driver
proper makes it possible to simplify the driver's .remove() routine,
because it doesn't need to worry about the possible cleanup related
to processor removal any more (the scan/hotplug part is responsible
for that now) and can handle device removal and driver removal
symmetricaly (i.e. as appropriate).
Some user-visible changes in sysfs are made (for example, the
'sysdev' link from the ACPI device node to the processor device's
directory is gone and a 'physical_node' link is present instead
and a corresponding 'firmware_node' is present in the processor
device's directory, the processor driver is now visible under
/sys/bus/cpu/drivers/ and bound to the processor device), but
that shouldn't affect the functionality that users care about
(frequency scaling, C-states and thermal management).
Tested on my venerable Toshiba Portege R500.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
2013-05-02 22:26:22 +00:00
|
|
|
}
|
2019-12-13 08:55:14 +00:00
|
|
|
|
|
|
|
#ifdef CONFIG_ACPI_PROCESSOR_CSTATE
|
|
|
|
/**
|
|
|
|
* acpi_processor_claim_cst_control - Request _CST control from the platform.
|
|
|
|
*/
|
|
|
|
bool acpi_processor_claim_cst_control(void)
|
|
|
|
{
|
|
|
|
static bool cst_control_claimed;
|
|
|
|
acpi_status status;
|
|
|
|
|
|
|
|
if (!acpi_gbl_FADT.cst_control || cst_control_claimed)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
status = acpi_os_write_port(acpi_gbl_FADT.smi_command,
|
|
|
|
acpi_gbl_FADT.cst_control, 8);
|
|
|
|
if (ACPI_FAILURE(status)) {
|
|
|
|
pr_warn("ACPI: Failed to claim processor _CST control\n");
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
cst_control_claimed = true;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(acpi_processor_claim_cst_control);
|
2019-12-13 08:55:42 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* acpi_processor_evaluate_cst - Evaluate the processor _CST control method.
|
|
|
|
* @handle: ACPI handle of the processor object containing the _CST.
|
|
|
|
* @cpu: The numeric ID of the target CPU.
|
|
|
|
* @info: Object write the C-states information into.
|
|
|
|
*
|
|
|
|
* Extract the C-state information for the given CPU from the output of the _CST
|
|
|
|
* control method under the corresponding ACPI processor object (or processor
|
|
|
|
* device object) and populate @info with it.
|
|
|
|
*
|
|
|
|
* If any ACPI_ADR_SPACE_FIXED_HARDWARE C-states are found, invoke
|
|
|
|
* acpi_processor_ffh_cstate_probe() to verify them and update the
|
|
|
|
* cpu_cstate_entry data for @cpu.
|
|
|
|
*/
|
|
|
|
int acpi_processor_evaluate_cst(acpi_handle handle, u32 cpu,
|
|
|
|
struct acpi_processor_power *info)
|
|
|
|
{
|
|
|
|
struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
|
|
|
|
union acpi_object *cst;
|
|
|
|
acpi_status status;
|
|
|
|
u64 count;
|
|
|
|
int last_index = 0;
|
|
|
|
int i, ret = 0;
|
|
|
|
|
|
|
|
status = acpi_evaluate_object(handle, "_CST", NULL, &buffer);
|
|
|
|
if (ACPI_FAILURE(status)) {
|
|
|
|
acpi_handle_debug(handle, "No _CST\n");
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
|
|
|
cst = buffer.pointer;
|
|
|
|
|
|
|
|
/* There must be at least 2 elements. */
|
|
|
|
if (!cst || cst->type != ACPI_TYPE_PACKAGE || cst->package.count < 2) {
|
|
|
|
acpi_handle_warn(handle, "Invalid _CST output\n");
|
|
|
|
ret = -EFAULT;
|
|
|
|
goto end;
|
|
|
|
}
|
|
|
|
|
|
|
|
count = cst->package.elements[0].integer.value;
|
|
|
|
|
|
|
|
/* Validate the number of C-states. */
|
|
|
|
if (count < 1 || count != cst->package.count - 1) {
|
|
|
|
acpi_handle_warn(handle, "Inconsistent _CST data\n");
|
|
|
|
ret = -EFAULT;
|
|
|
|
goto end;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 1; i <= count; i++) {
|
|
|
|
union acpi_object *element;
|
|
|
|
union acpi_object *obj;
|
|
|
|
struct acpi_power_register *reg;
|
|
|
|
struct acpi_processor_cx cx;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If there is not enough space for all C-states, skip the
|
|
|
|
* excess ones and log a warning.
|
|
|
|
*/
|
|
|
|
if (last_index >= ACPI_PROCESSOR_MAX_POWER - 1) {
|
|
|
|
acpi_handle_warn(handle,
|
|
|
|
"No room for more idle states (limit: %d)\n",
|
|
|
|
ACPI_PROCESSOR_MAX_POWER - 1);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
memset(&cx, 0, sizeof(cx));
|
|
|
|
|
|
|
|
element = &cst->package.elements[i];
|
|
|
|
if (element->type != ACPI_TYPE_PACKAGE)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (element->package.count != 4)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
obj = &element->package.elements[0];
|
|
|
|
|
|
|
|
if (obj->type != ACPI_TYPE_BUFFER)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
reg = (struct acpi_power_register *)obj->buffer.pointer;
|
|
|
|
|
|
|
|
obj = &element->package.elements[1];
|
|
|
|
if (obj->type != ACPI_TYPE_INTEGER)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
cx.type = obj->integer.value;
|
|
|
|
/*
|
|
|
|
* There are known cases in which the _CST output does not
|
|
|
|
* contain C1, so if the type of the first state found is not
|
|
|
|
* C1, leave an empty slot for C1 to be filled in later.
|
|
|
|
*/
|
|
|
|
if (i == 1 && cx.type != ACPI_STATE_C1)
|
|
|
|
last_index = 1;
|
|
|
|
|
|
|
|
cx.address = reg->address;
|
|
|
|
cx.index = last_index + 1;
|
|
|
|
|
|
|
|
if (reg->space_id == ACPI_ADR_SPACE_FIXED_HARDWARE) {
|
|
|
|
if (!acpi_processor_ffh_cstate_probe(cpu, &cx, reg)) {
|
|
|
|
/*
|
|
|
|
* In the majority of cases _CST describes C1 as
|
|
|
|
* a FIXED_HARDWARE C-state, but if the command
|
|
|
|
* line forbids using MWAIT, use CSTATE_HALT for
|
|
|
|
* C1 regardless.
|
|
|
|
*/
|
|
|
|
if (cx.type == ACPI_STATE_C1 &&
|
|
|
|
boot_option_idle_override == IDLE_NOMWAIT) {
|
|
|
|
cx.entry_method = ACPI_CSTATE_HALT;
|
|
|
|
snprintf(cx.desc, ACPI_CX_DESC_LEN, "ACPI HLT");
|
|
|
|
} else {
|
|
|
|
cx.entry_method = ACPI_CSTATE_FFH;
|
|
|
|
}
|
|
|
|
} else if (cx.type == ACPI_STATE_C1) {
|
|
|
|
/*
|
|
|
|
* In the special case of C1, FIXED_HARDWARE can
|
|
|
|
* be handled by executing the HLT instruction.
|
|
|
|
*/
|
|
|
|
cx.entry_method = ACPI_CSTATE_HALT;
|
|
|
|
snprintf(cx.desc, ACPI_CX_DESC_LEN, "ACPI HLT");
|
|
|
|
} else {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
} else if (reg->space_id == ACPI_ADR_SPACE_SYSTEM_IO) {
|
|
|
|
cx.entry_method = ACPI_CSTATE_SYSTEMIO;
|
|
|
|
snprintf(cx.desc, ACPI_CX_DESC_LEN, "ACPI IOPORT 0x%x",
|
|
|
|
cx.address);
|
|
|
|
} else {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (cx.type == ACPI_STATE_C1)
|
|
|
|
cx.valid = 1;
|
|
|
|
|
|
|
|
obj = &element->package.elements[2];
|
|
|
|
if (obj->type != ACPI_TYPE_INTEGER)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
cx.latency = obj->integer.value;
|
|
|
|
|
|
|
|
obj = &element->package.elements[3];
|
|
|
|
if (obj->type != ACPI_TYPE_INTEGER)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
memcpy(&info->states[++last_index], &cx, sizeof(cx));
|
|
|
|
}
|
|
|
|
|
|
|
|
acpi_handle_info(handle, "Found %d idle states\n", last_index);
|
|
|
|
|
|
|
|
info->count = last_index;
|
|
|
|
|
|
|
|
end:
|
|
|
|
kfree(buffer.pointer);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(acpi_processor_evaluate_cst);
|
2019-12-13 08:55:14 +00:00
|
|
|
#endif /* CONFIG_ACPI_PROCESSOR_CSTATE */
|