[ACPIHP PATCH part1 0/4] introduce a framework for ACPI based system device hotplug

[ACPIHP PATCH part1 0/4] introduce a framework for ACPI based system device hotplug

[Jiang Liu]

Modern high-end servers may support advanced RAS features, such as
system device dynamic reconfiguration. On x86 and IA64 platforms,
system device means processor(CPU), memory device, PCI host bridge
and even computer node.

The ACPI specifications have provided standard interfaces between
firmware and OS to support device dynamic reconfiguraiton at runtime.
This patch series introduces a new framework for system device
dynamic reconfiguration based on ACPI specification, which will
replace current existing system device hotplug logic embedded in
ACPI processor/memory/container device drivers.

The new ACPI based hotplug framework is modelled after the PCI hotplug
architecture and target to achieve following goals:
1) Optimize device configuration order to achieve best performance for
   hot-added system devices. For best perforamnce, system device should
   be configured in order of memory -> CPU -> IOAPIC/IOMMU -> PCI HB.
2) Resolve dependencies among hotplug slots. You need first to remove
   the memory device before removing a physical processor if a
   hotpluggable memory device is connected to a hotpluggable physical
   processor.
3) Provide interface to cancel ongoing hotplug operations. It may take
   a very long time to remove a memory device, so provide interface to
   cancel the inprogress hotplug operations.
4) Support new advanced RAS features, such as socket/memory migration.
5) Provide better user interfaces to access the hotplug functionalities.
6) Provide a mechanism to detect hotplug slots by checking existence
   of ACPI _EJ0 method or by other hardware platform specific methods.
7) Unify the way to enumerate ACPI based hotplug slots. All hotplug
   slots will be enumerated by the enumeration driver (acpihp_slot),
   instead of by individual ACPI device drivers.
8) Unify the way to handle ACPI hotplug events. All ACPI hotplug events
   for system devices will be handled by a generic ACPI hotplug driver
   (acpihp_drv) instead of by individual ACPI device drivers.
9) Provide better error handling and error recovery.
10) Trigger hotplug events/operations by software. This feature is useful
   for hardware fault management and/or power saving.

The new framework is composed up of three major components:
1) A system device hotplug slot enumerator driver, which enumerates
   hotplug slots in the system and provides platform specific methods
   to control those slots.
2) A system device hotplug driver, which is a platform independent
   driver to manage all hotplug slots created by the slot enumerator.
   The hotplug driver implements a state machine for hotplug slots and
   provides user interfaces to manage hotplug slots.
3) Several ACPI device drivers to configure/unconfigure system devices
   at runtime.

And the whole patchset will be split into 7 parts:
1) the hotplug slot enumeration driver (acpihp_slot)
2) the system device hotplug driver (acpihp_drv)
3) enhance ACPI container driver to support new framework
4) enhance ACPI processor driver to support new framework
5) enhance ACPI memory driver to support new framework
6) enhance ACPI host bridge driver to support new framework
7) enhancments and cleanups to the ACPI core

This is the first part of hotplug slot enumeration driver (acpihp_slot).
And you may pull from:
https://github.com/jiangliu/linux.git acpihp_slot

On loading, it will scan ACPI hotplug slots for system device hotplug.
For example, Intel Emerald Ridge/Quantum S4R platform has
1) 4 hotpluggable physical processors
2) 8 hotpluggable memory boards (each processor has two memory boards)
3) 1 hotpluggable IOH and 1 non-hotpluggable legacy IOH

#modprobe acpihp_slot
#cd /sys/bus/acpi/slots
#ls -l
total 0
lrwxrwxrwx  CPU00 -> ../../../devices/LNXSYSTM:00/acpihp/CPU00
lrwxrwxrwx  CPU01 -> ../../../devices/LNXSYSTM:00/acpihp/CPU01
lrwxrwxrwx  CPU02 -> ../../../devices/LNXSYSTM:00/acpihp/CPU02
lrwxrwxrwx  CPU03 -> ../../../devices/LNXSYSTM:00/acpihp/CPU03
lrwxrwxrwx  IOX01 -> ../../../devices/LNXSYSTM:00/acpihp/IOX01
lrwxrwxrwx  MEM00 -> ../../../devices/LNXSYSTM:00/acpihp/CPU00/MEM00
lrwxrwxrwx  MEM01 -> ../../../devices/LNXSYSTM:00/acpihp/CPU00/MEM01
lrwxrwxrwx  MEM02 -> ../../../devices/LNXSYSTM:00/acpihp/CPU01/MEM02
lrwxrwxrwx  MEM03 -> ../../../devices/LNXSYSTM:00/acpihp/CPU01/MEM03
lrwxrwxrwx  MEM04 -> ../../../devices/LNXSYSTM:00/acpihp/CPU02/MEM04
lrwxrwxrwx  MEM05 -> ../../../devices/LNXSYSTM:00/acpihp/CPU02/MEM05
lrwxrwxrwx  MEM06 -> ../../../devices/LNXSYSTM:00/acpihp/CPU03/MEM06
lrwxrwxrwx  MEM07 -> ../../../devices/LNXSYSTM:00/acpihp/CPU03/MEM07

For each hotplug slots, it provides following sysfs interfaces:
# cd CPU00/
# ls			; MEM00, MEM01 are child hotplug slots
MEM00  MEM01  capabilities  device  object  power  state  status  subsystem  uevent
# cat capabilities	; show slot RAS capabilities
online,offline,poweroff,hotplug
# cat object		; show ACPI object corresponding to this slot
\_SB_.SCK0
# cat state		; show slot state machine state
configured
# cat status		; show devie health status
ok

Jiang Liu (4):
  ACPIHP: introduce a framework for ACPI based system device hotplug
  ACPIHP: introduce acpihp_slot driver to enumerate hotplug slots
  ACPIHP: detect ACPI hotplug slots by checking ACPI _EJ0 method
  ACPIHP: implement a fake ACPI system device hotplug slot enumerator

 drivers/acpi/Kconfig             |   42 +++
 drivers/acpi/Makefile            |    2 +
 drivers/acpi/hotplug/Makefile    |   11 +
 drivers/acpi/hotplug/acpihp.h    |   36 +++
 drivers/acpi/hotplug/core.c      |  543 ++++++++++++++++++++++++++++++++++++++
 drivers/acpi/hotplug/slot.c      |  421 +++++++++++++++++++++++++++++
 drivers/acpi/hotplug/slot_ej0.c  |  143 ++++++++++
 drivers/acpi/hotplug/slot_fake.c |  180 +++++++++++++
 include/acpi/acpi_hotplug.h      |  208 +++++++++++++++
 9 files changed, 1586 insertions(+)
 create mode 100644 drivers/acpi/hotplug/Makefile
 create mode 100644 drivers/acpi/hotplug/acpihp.h
 create mode 100644 drivers/acpi/hotplug/core.c
 create mode 100644 drivers/acpi/hotplug/slot.c
 create mode 100644 drivers/acpi/hotplug/slot_ej0.c
 create mode 100644 drivers/acpi/hotplug/slot_fake.c
 create mode 100644 include/acpi/acpi_hotplug.h

-- 
1.7.9.5

[ACPIHP PATCH part1 1/4] ACPIHP: introduce a framework for ACPI based system device hotplug

[Jiang Liu]

Modern high-end servers may support advanced RAS features, such as
system device dynamic reconfiguration. On x86 and IA64 platforms,
system device means processor(CPU), memory device, PCI host bridge
and even computer node.

The ACPI specifications have provided standard interfaces between
firmware and OS to support device dynamic reconfiguraiton at runtime.
This patch series introduces a new framework for system device
dynamic reconfiguration based on ACPI specification, which will
replace current existing system device hotplug logic embedded in
ACPI processor/memory/container device drivers.

The new ACPI based hotplug framework is modelled after the PCI hotplug
architecture and target to achieve following goals:
1) Optimize device configuration order to achieve best performance for
   hot-added system devices. For best perforamnce, system device should
   be configured in order of memory -> CPU -> IOAPIC/IOMMU -> PCI HB.
2) Resolve dependencies among hotplug slots. You need first to remove
   the memory device before removing a physical processor if a
   hotpluggable memory device is connected to a hotpluggable physical
   processor.
3) Provide interface to cancel ongoing hotplug operations. It may take
   a very long time to remove a memory device, so provide interface to
   cancel the inprogress hotplug operations.
4) Support new advanced RAS features, such as socket/memory migration.
5) Provide better user interfaces to access the hotplug functionalities.
6) Provide a mechanism to detect hotplug slots by checking existence
   of ACPI _EJ0 method or by other hardware platform specific methods.
7) Unify the way to enumerate ACPI based hotplug slots. All hotplug
   slots will be enumerated by the enumeration driver (acpihp_slot),
   instead of by individual ACPI device drivers.
8) Unify the way to handle ACPI hotplug events. All ACPI hotplug events
   for system devices will be handled by a generic ACPI hotplug driver
   (acpihp_drv) instead of by individual ACPI device drivers.
9) Provide better error handling and error recovery.
10) Trigger hotplug events/operations by software. This feature is useful
   for hardware fault management and/or power saving.

The new framework is composed up of three major components:
1) A system device hotplug slot enumerator driver, which enumerates
   hotplug slots in the system and provides platform specific methods
   to control those slots.
2) A system device hotplug driver, which is a platform independent
   driver to manage all hotplug slots created by the slot enumerator.
   The hotplug driver implements a state machine for hotplug slots and
   provides user interfaces to manage hotplug slots.
3) Several ACPI device drivers to configure/unconfigure system devices
   at runtime.

To get rid of inter dependengcy between the slot enumerator and hotplug
driver, common code shared by them will be built into the kernel. The
shared code provides some helper routines and a device class named
acpihp_slot_class with following default sysfs properties:
	capabilities: RAS capabilities of the hotplug slot
	state: current state of the hotplug slot state machine
	status: current health status of the hotplug slot
	object: ACPI object corresponding to the hotplug slot

Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Signed-off-by: Gaohuai Han <hangaohuai@huawei.com>
---
 drivers/acpi/Kconfig          |   13 +
 drivers/acpi/Makefile         |    2 +
 drivers/acpi/hotplug/Makefile |    6 +
 drivers/acpi/hotplug/acpihp.h |   32 +++
 drivers/acpi/hotplug/core.c   |  543 +++++++++++++++++++++++++++++++++++++++++
 include/acpi/acpi_hotplug.h   |  208 ++++++++++++++++
 6 files changed, 804 insertions(+)
 create mode 100644 drivers/acpi/hotplug/Makefile
 create mode 100644 drivers/acpi/hotplug/acpihp.h
 create mode 100644 drivers/acpi/hotplug/core.c
 create mode 100644 include/acpi/acpi_hotplug.h

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 119d58d..9577b23 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -321,6 +321,19 @@ config X86_PM_TIMER
 	  You should nearly always say Y here because many modern
 	  systems require this timer. 
 
+menuconfig ACPI_HOTPLUG
+	bool "System Device Hotplug"
+	depends on (X86 || IA64) && SYSFS
+	default n
+	help
+	  This option enables a framework to dynamically reconfigure system
+	  devices at runtime based on ACPI specifications. On x86 and IA64
+	  platforms, system device includes processor(CPU), memory device,
+	  PCI/PCIe host bridge and computer node etc.
+
+	  If your hardware platform does not support system device dynamic
+	  reconfiguration at runtime, you need not to enable this option.
+
 config ACPI_CONTAINER
 	tristate "Container and Module Devices (EXPERIMENTAL)"
 	depends on EXPERIMENTAL
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 47199e2..17bea6c 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -73,3 +73,5 @@ obj-$(CONFIG_ACPI_PROCESSOR_AGGREGATOR) += acpi_pad.o
 obj-$(CONFIG_ACPI_IPMI)		+= acpi_ipmi.o
 
 obj-$(CONFIG_ACPI_APEI)		+= apei/
+
+obj-$(CONFIG_ACPI_HOTPLUG)	+= hotplug/
diff --git a/drivers/acpi/hotplug/Makefile b/drivers/acpi/hotplug/Makefile
new file mode 100644
index 0000000..5e7790f
--- /dev/null
+++ b/drivers/acpi/hotplug/Makefile
@@ -0,0 +1,6 @@
+#
+# Makefile for ACPI based system device hotplug drivers
+#
+
+obj-$(CONFIG_ACPI_HOTPLUG)			+= acpihp.o
+acpihp-y					= core.o
diff --git a/drivers/acpi/hotplug/acpihp.h b/drivers/acpi/hotplug/acpihp.h
new file mode 100644
index 0000000..7467895
--- /dev/null
+++ b/drivers/acpi/hotplug/acpihp.h
@@ -0,0 +1,32 @@
+/*
+ * Copyright (C) 2012 Huawei Tech. Co., Ltd.
+ * Copyright (C) 2012 Jiang Liu <jiang.liu@huawei.com>
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ */
+
+#ifndef	ACPIHP_INTERNAL_H
+#define	ACPIHP_INTERNAL_H
+#include <acpi/acpi.h>
+#include <acpi/acpi_bus.h>
+#include <acpi/acpi_hotplug.h>
+
+extern struct acpi_device *acpi_root;
+
+#endif
diff --git a/drivers/acpi/hotplug/core.c b/drivers/acpi/hotplug/core.c
new file mode 100644
index 0000000..c835a97
--- /dev/null
+++ b/drivers/acpi/hotplug/core.c
@@ -0,0 +1,543 @@
+/*
+ * Copyright (C) 2012 Huawei Tech. Co., Ltd.
+ * Copyright (C) 2012 Jiang Liu <jiang.liu@huawei.com>
+ * Copyright (C) 2012 Gaohuai Han <hangaohuai@huawei.com>
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ */
+
+#include <linux/types.h>
+#include <linux/module.h>
+#include <linux/acpi.h>
+#include <linux/bug.h>
+#include <linux/device.h>
+#include <linux/mutex.h>
+#include <linux/sem.h>
+#include <linux/version.h>
+#include <acpi/acpi.h>
+#include <acpi/acpi_bus.h>
+#include <acpi/acpi_hotplug.h>
+#include "acpihp.h"
+
+#define to_acpihp_slot(d) container_of(d, struct acpihp_slot, dev)
+
+static DEFINE_MUTEX(acpihp_mutex);
+static int acpihp_class_count;
+static struct kset *acpihp_slot_kset;
+
+static char *acpihp_slot_names[ACPIHP_SLOT_TYPE_MAX] = {
+	[ACPIHP_SLOT_TYPE_UNKNOWN]	= "UNKNOWN",
+	[ACPIHP_SLOT_TYPE_COMMON]	= "SLOT",
+	[ACPIHP_SLOT_TYPE_NODE]		= "NODE",
+	[ACPIHP_SLOT_TYPE_SYSTEM_BOARD]	= "SB",
+	[ACPIHP_SLOT_TYPE_CPU]		= "CPU",
+	[ACPIHP_SLOT_TYPE_MEM]		= "MEM",
+	[ACPIHP_SLOT_TYPE_IOX]		= "IOX",
+};
+
+static char *acpihp_slot_states[] = {
+	[ACPIHP_SLOT_STATE_UNKNOWN]		= "unknown",
+	[ACPIHP_SLOT_STATE_ABSENT]		= "absent",
+	[ACPIHP_SLOT_STATE_PRESENT]		= "present",
+	[ACPIHP_SLOT_STATE_POWERED]		= "powered",
+	[ACPIHP_SLOT_STATE_CONNECTED]		= "connected",
+	[ACPIHP_SLOT_STATE_CONFIGURED]		= "configured",
+	[ACPIHP_SLOT_STATE_POWERING_ON]		= "powering on",
+	[ACPIHP_SLOT_STATE_POWERING_OFF]	= "powering off",
+	[ACPIHP_SLOT_STATE_CONNECTING]		= "connecting",
+	[ACPIHP_SLOT_STATE_DISCONNECTING]	= "disconneting",
+	[ACPIHP_SLOT_STATE_CONFIGURING]		= "configuring",
+	[ACPIHP_SLOT_STATE_UNCONFIGURING]	= "unconfiguring",
+};
+
+static char *acpihp_slot_status[] = {
+	"ok",
+	"irremovable",
+	"fault",
+	"irremovable, fault",
+};
+
+static char *acpihp_dev_container_ids[] = {
+	"ACPI0004",
+	"PNP0A05",
+	"PNP0A06",
+	NULL
+};
+
+static char *acpihp_dev_cpu_ids[] = {
+	"ACPI0007",
+	"LNXCPU",
+	NULL
+};
+
+static char *acpihp_dev_mem_ids[] = {
+	"PNP0C80",
+	NULL
+};
+
+static char *acpihp_dev_pcihb_ids[] = {
+	"PNP0A03",
+	NULL
+};
+
+static void acpihp_slot_release(struct device *dev)
+{
+	struct acpihp_slot *slot = to_acpihp_slot(dev);
+
+	kfree(slot);
+}
+
+/**
+ * acpihp_alloc_slot - allocate a hotplug slot for @handle
+ * @handle: the ACPI device handle to associated with the hotplug slot
+ * @name: optional name for the hotplug slot
+ *
+ * The returned data structure must be freed by calling acpihp_slot_put()
+ * instead of kfree().
+ */
+struct acpihp_slot *acpihp_alloc_slot(acpi_handle handle, char *name)
+{
+	struct acpihp_slot *slot;
+
+	if (name && strlen(name) >= ACPIHP_SLOT_NAME_MAX_SIZE) {
+		ACPIHP_DEBUG("slot name '%s' is too big.\n", name);
+		return NULL;
+	}
+
+	slot = kzalloc(sizeof(*slot), GFP_KERNEL);
+	if (slot == NULL) {
+		ACPIHP_DEBUG("fails to allocate memory for slot device.\n");
+		return NULL;
+	}
+
+	slot->handle = handle;
+	INIT_LIST_HEAD(&slot->slot_list);
+	INIT_LIST_HEAD(&slot->drvdata_list);
+	if (name)
+		strncpy(slot->name, name, sizeof(slot->name) - 1);
+	mutex_init(&slot->slot_mutex);
+
+	slot->dev.class = &acpihp_slot_class;
+	device_initialize(&slot->dev);
+
+	return slot;
+}
+EXPORT_SYMBOL_GPL(acpihp_alloc_slot);
+
+int acpihp_register_slot(struct acpihp_slot *slot)
+{
+	int ret;
+
+	if (!slot || !slot->slot_ops)
+		return -EINVAL;
+
+	/* Use ACPI root device to host top level hotplug slots */
+	if (slot->parent)
+		slot->dev.parent = &slot->parent->dev;
+	else
+		slot->dev.parent = &acpi_root->dev;
+
+	ret = device_add(&slot->dev);
+	if (!ret) {
+		slot->flags |= ACPIHP_SLOT_FLAG_REGISTERED;
+		if (sysfs_create_link(&acpihp_slot_kset->kobj, &slot->dev.kobj,
+				      slot->name))
+			dev_warn(&slot->dev, "fails to create symlink.\n");
+	}
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(acpihp_register_slot);
+
+void acpihp_unregister_slot(struct acpihp_slot *slot)
+{
+	if (slot && (slot->flags & ACPIHP_SLOT_FLAG_REGISTERED)) {
+		sysfs_remove_link(&acpihp_slot_kset->kobj, slot->name);
+		device_del(&slot->dev);
+		slot->flags &= ~ACPIHP_SLOT_FLAG_REGISTERED;
+	}
+}
+EXPORT_SYMBOL_GPL(acpihp_unregister_slot);
+
+struct acpihp_slot *acpihp_slot_get(struct acpihp_slot *slot)
+{
+	if (slot)
+		get_device(&slot->dev);
+
+	return slot;
+}
+EXPORT_SYMBOL_GPL(acpihp_slot_get);
+
+void acpihp_slot_put(struct acpihp_slot *slot)
+{
+	if (slot)
+		put_device(&slot->dev);
+}
+EXPORT_SYMBOL_GPL(acpihp_slot_put);
+
+static void acpihp_slot_data_handler(acpi_handle handle, void *context)
+{
+	return;
+}
+
+/* Bind the slot device to corresponding ACPI object handle */
+acpi_status acpihp_mark_slot(acpi_handle handle, struct acpihp_slot *slot)
+{
+	acpi_status status;
+
+	mutex_lock(&acpihp_mutex);
+	status = acpi_attach_data(handle, &acpihp_slot_data_handler, slot);
+	mutex_unlock(&acpihp_mutex);
+
+	return status;
+}
+EXPORT_SYMBOL_GPL(acpihp_mark_slot);
+
+acpi_status acpihp_unmark_slot(acpi_handle handle)
+{
+	acpi_status result;
+
+	mutex_lock(&acpihp_mutex);
+	result = acpi_detach_data(handle, &acpihp_slot_data_handler);
+	if (result == AE_NOT_FOUND)
+		result = AE_OK;
+	BUG_ON(result != AE_OK);
+	mutex_unlock(&acpihp_mutex);
+
+	return result;
+}
+EXPORT_SYMBOL_GPL(acpihp_unmark_slot);
+
+bool acpihp_is_slot(acpi_handle handle)
+{
+	acpi_status result;
+	void *data = NULL;
+
+	result = acpi_get_data(handle, &acpihp_slot_data_handler, &data);
+	BUG_ON(result != AE_OK && result != AE_NOT_FOUND);
+
+	return (result == AE_OK);
+}
+EXPORT_SYMBOL_GPL(acpihp_is_slot);
+
+struct acpihp_slot *acpihp_get_slot(acpi_handle handle)
+{
+	acpi_status result;
+	void *data = NULL;
+	struct acpihp_slot *slot = NULL;
+
+	mutex_lock(&acpihp_mutex);
+	result = acpi_get_data(handle, &acpihp_slot_data_handler, &data);
+	if (ACPI_SUCCESS(result) && data) {
+		slot = data;
+		acpihp_slot_get(slot);
+	}
+	mutex_unlock(&acpihp_mutex);
+
+	return slot;
+}
+EXPORT_SYMBOL_GPL(acpihp_get_slot);
+
+bool acpihp_dev_match_ids(struct acpi_device_info *infop, char **ids)
+{
+	int i, j;
+	struct acpica_device_id_list *cid_list;
+
+	if (infop == NULL || ids == NULL) {
+		ACPIHP_DEBUG("invalid parameters.\n");
+		return false;
+	}
+
+	if (infop->valid & ACPI_VALID_HID) {
+		for (i = 0; ids[i]; i++) {
+			if (strncmp(ids[i], infop->hardware_id.string,
+				    infop->hardware_id.length) == 0) {
+				return true;
+			}
+		}
+	}
+
+	if (infop->valid & ACPI_VALID_CID) {
+		for (i = 0; ids[i]; i++) {
+			cid_list = &infop->compatible_id_list;
+			for (j = 0; j < cid_list->count; j++) {
+				if (strncmp(ids[i],
+					    cid_list->ids[j].string,
+					    cid_list->ids[j].length) == 0) {
+						return true;
+				}
+			}
+		}
+	}
+
+	return false;
+}
+EXPORT_SYMBOL_GPL(acpihp_dev_match_ids);
+
+int acpihp_dev_get_type(acpi_handle handle, enum acpihp_dev_type *type)
+{
+	struct acpi_device_info *infop = NULL;
+
+	if (handle == NULL || type == NULL) {
+		ACPIHP_DEBUG("invalid parameters.\n");
+		return -EINVAL;
+	}
+	if (ACPI_FAILURE(acpi_get_object_info(handle, &infop)))
+		return -ENODEV;
+
+	*type = ACPIHP_DEV_TYPE_UNKNOWN;
+	if (infop->type == ACPI_TYPE_PROCESSOR) {
+		*type = ACPIHP_DEV_TYPE_CPU;
+	} else if (infop->type == ACPI_TYPE_DEVICE) {
+		if (acpihp_dev_match_ids(infop, acpihp_dev_container_ids))
+			*type = ACPIHP_DEV_TYPE_CONTAINER;
+		else if (acpihp_dev_match_ids(infop, acpihp_dev_cpu_ids))
+			*type = ACPIHP_DEV_TYPE_CPU;
+		else if (acpihp_dev_match_ids(infop, acpihp_dev_mem_ids))
+			*type = ACPIHP_DEV_TYPE_MEM;
+		else if (acpihp_dev_match_ids(infop, acpihp_dev_pcihb_ids))
+			*type = ACPIHP_DEV_TYPE_HOST_BRIDGE;
+		else if ((infop->valid & (ACPI_VALID_ADR | ACPI_VALID_HID |
+			 ACPI_VALID_CID)) == ACPI_VALID_ADR)
+			*type = ACPIHP_DEV_TYPE_MAX;
+	}
+	kfree(infop);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(acpihp_dev_get_type);
+
+char *acpihp_get_slot_type_name(enum acpihp_slot_type type)
+{
+	if (type < 0 || type >= ACPIHP_SLOT_TYPE_MAX) {
+		ACPIHP_DEBUG("invalid parameters.\n");
+		return "UNKNOWN";
+	}
+
+	return acpihp_slot_names[type];
+}
+EXPORT_SYMBOL_GPL(acpihp_get_slot_type_name);
+
+acpi_status acpihp_slot_get_status(struct acpihp_slot *slot, u64 *status)
+{
+	acpi_status rc;
+
+	if (slot == NULL || status == NULL) {
+		ACPIHP_DEBUG("invalid parameters.\n");
+		return AE_BAD_PARAMETER;
+	} else if (slot->slot_ops == NULL) {
+		ACPIHP_SLOT_DEBUG(slot, "operation not supported.\n");
+		return AE_SUPPORT;
+	} else if (slot->slot_ops->get_status)
+		return slot->slot_ops->get_status(slot, status);
+
+	rc = acpi_evaluate_integer(slot->handle, METHOD_NAME__STA,
+				   NULL, status);
+	if (rc == AE_NOT_FOUND) {
+		*status = ACPI_STA_DEVICE_PRESENT | ACPI_STA_DEVICE_ENABLED |
+			  ACPI_STA_DEVICE_FUNCTIONING;
+		rc = AE_OK;
+	}
+
+	return rc;
+}
+EXPORT_SYMBOL_GPL(acpihp_slot_get_status);
+
+acpi_status acpihp_slot_poweron(struct acpihp_slot *slot)
+{
+	if (slot == NULL) {
+		ACPIHP_DEBUG("invalid parameter.\n");
+		return AE_BAD_PARAMETER;
+	} else if (slot->slot_ops == NULL || slot->slot_ops->poweron == NULL) {
+		ACPIHP_SLOT_DEBUG(slot, "operation not supported.\n");
+		return AE_SUPPORT;
+	}
+
+	return slot->slot_ops->poweron(slot->handle);
+}
+EXPORT_SYMBOL_GPL(acpihp_slot_poweron);
+
+acpi_status acpihp_slot_poweroff(struct acpihp_slot *slot)
+{
+	if (slot == NULL) {
+		ACPIHP_DEBUG("invalid parameter.\n");
+		return AE_BAD_PARAMETER;
+	} else if (slot->slot_ops == NULL || slot->slot_ops->poweroff == NULL) {
+		ACPIHP_SLOT_DEBUG(slot, "operation not supported.\n");
+		return AE_SUPPORT;
+	}
+
+	return slot->slot_ops->poweroff(slot->handle);
+}
+EXPORT_SYMBOL_GPL(acpihp_slot_poweroff);
+
+/* SYSFS interfaces */
+static ssize_t acpihp_slot_object_show(struct device *d,
+		struct device_attribute *attr, char *buf)
+{
+	acpi_status rc;
+	ssize_t sz = -EINVAL;
+	struct acpihp_slot *slot = to_acpihp_slot(d);
+	struct acpi_buffer path = {ACPI_ALLOCATE_BUFFER, NULL};
+
+	rc = acpi_get_name(slot->handle, ACPI_FULL_PATHNAME, &path);
+	if (ACPI_SUCCESS(rc)) {
+		sz = snprintf(buf, PAGE_SIZE, "%s\n", (char *)path.pointer);
+		kfree(path.pointer);
+	}
+
+	return sz;
+}
+
+static ssize_t acpihp_slot_state_show(struct device *d,
+		struct device_attribute *attr, char *buf)
+{
+	enum acpihp_slot_state state;
+	acpi_status status;
+	unsigned long long sta;
+	struct acpihp_slot *slot = to_acpihp_slot(d);
+
+	state = slot->state < 0 || slot->state >= ACPIHP_SLOT_STATE_MAX ?
+		ACPIHP_SLOT_STATE_UNKNOWN : slot->state;
+
+	/*
+	 * There's no standard ACPI interfaces to notify the hotplug driver
+	 * when device presence changes, so check it for sure.
+	 */
+	if (ACPIHP_SLOT_STATE_ABSENT == state ||
+	    ACPIHP_SLOT_STATE_PRESENT == state) {
+		status = acpihp_slot_get_status(slot, &sta);
+		if (ACPI_SUCCESS(status)) {
+			if (sta & ACPI_STA_DEVICE_PRESENT)
+				state = ACPIHP_SLOT_STATE_PRESENT;
+			else
+				state = ACPIHP_SLOT_STATE_ABSENT;
+		}
+	}
+
+	return snprintf(buf, PAGE_SIZE, "%s\n", acpihp_slot_states[state]);
+}
+
+static ssize_t acpihp_slot_status_show(struct device *d,
+		struct device_attribute *attr, char *buf)
+{
+	struct acpihp_slot *slot = to_acpihp_slot(d);
+	u32 status = slot->flags & ACPIHP_SLOT_STATUS_MASK;
+
+	return snprintf(buf, PAGE_SIZE, "%s\n", acpihp_slot_status[status]);
+}
+
+static ssize_t acpihp_slot_capabilities_show(struct device *d,
+		struct device_attribute *attr, char *buf)
+{
+	ssize_t sz;
+	struct acpihp_slot *slot = to_acpihp_slot(d);
+	u32 cap = slot->capabilities;
+
+	sz = snprintf(buf, PAGE_SIZE, "%s%s%s%s%s%s",
+		(cap & ACPIHP_SLOT_CAP_ONLINE) ? "online," : "",
+		(cap & ACPIHP_SLOT_CAP_OFFLINE) ? "offline," : "",
+		(cap & ACPIHP_SLOT_CAP_POWERON) ? "poweron," : "",
+		(cap & ACPIHP_SLOT_CAP_POWEROFF) ? "poweroff," : "",
+		(cap & ACPIHP_SLOT_CAP_HOTPLUG) ? "hotplug," : "",
+		(cap & ACPIHP_SLOT_CAP_MIGRATE) ? "migrate," : "");
+
+	/* Change the last ',' to '\n' */
+	BUG_ON(sz == 0);
+	if (sz)
+		buf[sz - 1] = '\n';
+
+	return sz;
+}
+
+struct device_attribute acpihp_slot_dev_attrs[] = {
+	__ATTR(object, S_IRUGO, acpihp_slot_object_show, NULL),
+	__ATTR(state, S_IRUGO, acpihp_slot_state_show, NULL),
+	__ATTR(status, S_IRUGO, acpihp_slot_status_show, NULL),
+	__ATTR(capabilities, S_IRUGO, acpihp_slot_capabilities_show, NULL),
+	__ATTR_NULL
+};
+
+/* The device class to support ACPI hotplug slots. */
+struct class acpihp_slot_class = {
+	.name		= "acpihp",
+	.dev_release	= &acpihp_slot_release,
+	.dev_attrs	= acpihp_slot_dev_attrs,
+};
+EXPORT_SYMBOL_GPL(acpihp_slot_class);
+
+/* Initialize the ACPI based system device hotplug core logic */
+int acpihp_core_init(void)
+{
+	int retval = 0;
+	struct kset *acpi_bus_kset;
+
+	mutex_lock(&acpihp_mutex);
+	BUG_ON(acpihp_class_count < 0);
+
+	if (acpihp_class_count == 0) {
+		/* create directory /sys/bus/acpi/slots */
+		acpi_bus_kset = bus_get_kset(&acpi_bus_type);
+		acpihp_slot_kset = kset_create_and_add("slots", NULL,
+						       &acpi_bus_kset->kobj);
+		if (!acpihp_slot_kset) {
+			ACPIHP_DEBUG("fails to create kset.\n");
+			retval = -ENOMEM;
+			goto out_unlock;
+		}
+
+		retval = class_register(&acpihp_slot_class);
+		if (retval) {
+			ACPIHP_DEBUG("fails to register acpihp_slot_class.\n");
+			kset_unregister(acpihp_slot_kset);
+			goto out_unlock;
+		}
+	}
+
+	acpihp_class_count++;
+out_unlock:
+	mutex_unlock(&acpihp_mutex);
+
+	return retval;
+}
+EXPORT_SYMBOL_GPL(acpihp_core_init);
+
+/* Deinitialize the ACPI based system device hotplug core logic */
+void acpihp_core_fini(void)
+{
+	mutex_lock(&acpihp_mutex);
+	BUG_ON(acpihp_class_count <= 0);
+	--acpihp_class_count;
+	if (acpihp_class_count == 0) {
+		class_unregister(&acpihp_slot_class);
+		kset_unregister(acpihp_slot_kset);
+		acpihp_slot_kset = NULL;
+	}
+	mutex_unlock(&acpihp_mutex);
+}
+EXPORT_SYMBOL_GPL(acpihp_core_fini);
+
+#ifdef	DEBUG
+int acpihp_debug = 1;
+#else
+int acpihp_debug;
+#endif
+EXPORT_SYMBOL_GPL(acpihp_debug);
+module_param_named(debug, acpihp_debug, int, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(debug, "Enable debug mode");
diff --git a/include/acpi/acpi_hotplug.h b/include/acpi/acpi_hotplug.h
new file mode 100644
index 0000000..298f679
--- /dev/null
+++ b/include/acpi/acpi_hotplug.h
@@ -0,0 +1,208 @@
+/*
+ * Copyright (C) 2012 Huawei Tech. Co., Ltd.
+ * Copyright (C) 2012 Jiang Liu <jiang.liu@huawei.com>
+ * Copyright (C) 2012 Gaohuai Han <hangaohuai@huawei.com>
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ */
+
+#ifndef	__ACPI_HOTPLUG_H__
+#define	__ACPI_HOTPLUG_H__
+#include <linux/types.h>
+#include <linux/device.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/klist.h>
+#include <acpi/acpi.h>
+#include <acpi/acpi_drivers.h>
+
+#ifdef	CONFIG_ACPI_HOTPLUG
+
+#define	ACPIHP_SLOT_NAME_MAX_SIZE		16
+
+/* Types of system devices supported by the ACPI hotplug framework. */
+enum acpihp_dev_type {
+	ACPIHP_DEV_TYPE_UNKNOWN = 0,	/* Unknown device type */
+	ACPIHP_DEV_TYPE_CONTAINER,	/* ACPI container device */
+	ACPIHP_DEV_TYPE_MEM,		/* Memory device */
+	ACPIHP_DEV_TYPE_CPU,		/* Logical CPU device */
+	ACPIHP_DEV_TYPE_HOST_BRIDGE,	/* PCI/PCIe host bridge */
+	ACPIHP_DEV_TYPE_MAX
+};
+
+/*
+ * ACPI hotplug slot is an abstraction of receptacles where a group of
+ * system devices could be attached, just like PCI slot in PCI hotplug.
+ */
+enum acpihp_slot_type {
+	ACPIHP_SLOT_TYPE_UNKNOWN = 0,	/* Unknown slot type */
+	ACPIHP_SLOT_TYPE_COMMON,	/* Generic hotplug slot */
+	ACPIHP_SLOT_TYPE_NODE,		/* Node hosts CPU, MEM & IO devices */
+	ACPIHP_SLOT_TYPE_SYSTEM_BOARD,	/* System board hosts CPU & MEM */
+	ACPIHP_SLOT_TYPE_CPU,		/* CPU board */
+	ACPIHP_SLOT_TYPE_MEM,		/* Memory board */
+	ACPIHP_SLOT_TYPE_IOX,		/* IO eXtension board */
+	ACPIHP_SLOT_TYPE_MAX
+};
+
+/*
+ * State machine for ACPI hotplug slot:
+ *                     (POWERON)      (CONNECT)      (CONFIGURE)
+ * [ABSENT] <-> [PRESENT] <-> [POWERED] <-> [CONNECTED] <-> [CONFIGURED]
+ *                     (POWEROFF)    (DISCONNECT)   (UNCONFIGURE)
+ *
+ * [ABSENT]: no devices attached to the slot
+ * [PRESENT]: devices attached to the slot but powered off
+ * [POWERED]: devices attached to the slot have been powered on
+ * [CONNECTED]: ACPI device objects have been created for devices attached
+ *              to the slot, and ACPI device drivers have been bound to the
+ *              ACPI device objects
+ * [CONFIGURED]: devices attached to the slot have been added into the
+ *               running system
+ */
+enum acpihp_slot_state {
+	ACPIHP_SLOT_STATE_UNKNOWN = 0,
+	ACPIHP_SLOT_STATE_ABSENT,	/* slot is empty. */
+	ACPIHP_SLOT_STATE_PRESENT,	/* slot is populated. */
+	ACPIHP_SLOT_STATE_POWERED,	/* attached devices are powered. */
+	ACPIHP_SLOT_STATE_CONNECTED,	/* ACPI device nodes created. */
+	ACPIHP_SLOT_STATE_CONFIGURED,	/* attached devices are configured. */
+	ACPIHP_SLOT_STATE_POWERING_ON,	/* powering devices on */
+	ACPIHP_SLOT_STATE_POWERING_OFF,	/* powering devices off */
+	ACPIHP_SLOT_STATE_CONNECTING,	/* creating ACPI device nodes */
+	ACPIHP_SLOT_STATE_DISCONNECTING,/* destroying ACPI device nodes */
+	ACPIHP_SLOT_STATE_CONFIGURING,	/* configuring devices */
+	ACPIHP_SLOT_STATE_UNCONFIGURING,/* unconfigure devices */
+	ACPIHP_SLOT_STATE_MAX
+};
+
+/* Devices attached to the slot can't be hot-removed. */
+#define	ACPIHP_SLOT_FLAG_IRREMOVABLE	0x1
+/* Devices attached to the slot have encountered serious problems. */
+#define	ACPIHP_SLOT_FLAG_FAULT		0x2
+#define	ACPIHP_SLOT_STATUS_MASK		0x3
+/* Internal flag: devices attached to the slot have been registered. */
+#define	ACPIHP_SLOT_FLAG_REGISTERED	0x80000000
+
+/* Capabilities of ACPI hotplug slot. */
+#define	ACPIHP_SLOT_CAP_ONLINE		0x1  /* Logical online */
+#define	ACPIHP_SLOT_CAP_OFFLINE		0x2  /* Logical offline */
+#define	ACPIHP_SLOT_CAP_POWERON		0x4  /* Physical power on */
+#define	ACPIHP_SLOT_CAP_POWEROFF	0x8  /* Physical power off */
+#define	ACPIHP_SLOT_CAP_HOTPLUG		0x10 /* Physical hotplug */
+#define	ACPIHP_SLOT_CAP_MIGRATE		0x20 /* Device migration */
+
+struct acpihp_slot;
+
+/*
+ * Callbacks provided by the platform dependent hotplug slot enumeration driver,
+ * which will be used by the platform independent ACPI hotplug framework to
+ * manage and control ACPI hotplug slots.
+ */
+struct acpihp_slot_ops {
+	struct module *owner;
+	char *desc;
+	acpi_status (*init)(void);
+	void (*fini)(void);					/* optional */
+	acpi_status (*check)(acpi_handle handle);
+	acpi_status (*create)(struct acpihp_slot *slot);
+	void (*destroy)(struct acpihp_slot *slot);		/* optional */
+	acpi_status (*poweron)(struct acpihp_slot *slot);	/* optional */
+	acpi_status (*poweroff)(struct acpihp_slot *slot);	/* optional */
+	acpi_status (*get_status)(struct acpihp_slot *slot,
+				  u64 *status);			/* optional */
+};
+
+/* Device structure for ACPI hotplug slots. */
+struct acpihp_slot {
+	struct device			dev;
+	acpi_handle			handle;
+	u32				capabilities;
+	u32				flags;
+	enum acpihp_slot_type		type;
+	enum acpihp_slot_state		state;
+	struct acpihp_slot		*parent;
+	struct acpihp_slot_ops		*slot_ops;
+	void				*slot_data;
+	struct mutex			slot_mutex;
+	struct list_head		slot_list;
+	struct list_head		drvdata_list;
+	struct klist			dev_lists[ACPIHP_DEV_TYPE_MAX];
+	char				name[ACPIHP_SLOT_NAME_MAX_SIZE];
+};
+
+/* Device class for ACPI hotplug slots */
+extern struct class acpihp_slot_class;
+
+/* Initialize the ACPI based system device hotplug core logic */
+extern int acpihp_core_init(void);
+
+/* Deinitialize the ACPI based system device hotplug core logic */
+extern void acpihp_core_fini(void);
+
+/* Utility routines */
+extern int acpihp_dev_get_type(acpi_handle handle, enum acpihp_dev_type *type);
+extern bool acpihp_dev_match_ids(struct acpi_device_info *infop, char **ids);
+extern char *acpihp_get_slot_type_name(enum acpihp_slot_type type);
+
+/* Mark/unmark an ACPI object as an ACPI hotplug slot. */
+extern acpi_status acpihp_mark_slot(acpi_handle handle,
+				    struct acpihp_slot *slot);
+extern acpi_status acpihp_unmark_slot(acpi_handle handle);
+
+/* Check whether the ACPI object is a hotplug slot. */
+extern bool acpihp_is_slot(acpi_handle handle);
+
+/* Interfaces to manage ACPI hotplug slots */
+extern struct acpihp_slot *acpihp_alloc_slot(acpi_handle handle, char *name);
+extern int acpihp_register_slot(struct acpihp_slot *slot);
+extern void acpihp_unregister_slot(struct acpihp_slot *slot);
+extern struct acpihp_slot *acpihp_slot_get(struct acpihp_slot *slot);
+extern void acpihp_slot_put(struct acpihp_slot *slot);
+extern struct acpihp_slot *acpihp_get_slot(acpi_handle handle);
+
+/* Platform dependent hotplug hooks */
+extern acpi_status acpihp_slot_get_status(struct acpihp_slot *slot,
+					  u64 *status);
+extern acpi_status acpihp_slot_poweron(struct acpihp_slot *slot);
+extern acpi_status acpihp_slot_poweroff(struct acpihp_slot *slot);
+
+extern int acpihp_debug;
+
+#define ACPIHP_WARN(fmt, ...) \
+	pr_warn("acpihp@%s: " fmt,  __func__, ##__VA_ARGS__)
+
+#define ACPIHP_DEBUG(fmt, ...) \
+	do { \
+		if (acpihp_debug & 0x01) \
+			pr_warn("acpihp@%s: " fmt,  __func__, ##__VA_ARGS__); \
+	} while (0)
+
+#define	ACPIHP_SLOT_DEBUG(slot, fmt, ...) \
+	do { \
+		if (acpihp_debug & 0x01) \
+			dev_warn(&(slot)->dev, fmt, ##__VA_ARGS__); \
+	} while (0)
+
+#define	ACPIHP_SLOT_WARN(slot, fmt, ...) \
+	dev_warn(&(slot)->dev, fmt, ##__VA_ARGS__)
+
+#endif	/* CONFIG_ACPI_HOTPLUG */
+
+#endif	/* __ACPI_HOTPLUG_H__ */
-- 
1.7.9.5

[ACPIHP PATCH part1 2/4] ACPIHP: introduce acpihp_slot driver to enumerate hotplug slots

[Jiang Liu]

An ACPI hotplug slot is an abstraction of receptacles, where a group of
system devices could be connected to. This patch implements the skeleton
of the ACPI system device hotplug slot enumerator. On loading, it scans
the whole ACPI namespace for hotplug slots and creates a device node for
each hotplug slot found. Every hotplug slot is associated with a device
class named acpihp_slot_class. Later hotplug drivers will register onto
acpihp_slot_class to manage all hotplug slots.

Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Signed-off-by: Gaohuai Han <hangaohuai@huawei.com>
---
 drivers/acpi/Kconfig          |   19 ++
 drivers/acpi/hotplug/Makefile |    3 +
 drivers/acpi/hotplug/slot.c   |  417 +++++++++++++++++++++++++++++++++++++++++
 3 files changed, 439 insertions(+)
 create mode 100644 drivers/acpi/hotplug/slot.c

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 9577b23..af0aaf6 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -334,6 +334,25 @@ menuconfig ACPI_HOTPLUG
 	  If your hardware platform does not support system device dynamic
 	  reconfiguration at runtime, you need not to enable this option.
 
+config ACPI_HOTPLUG_SLOT
+	tristate "System Device Hotplug Slot Enumerator"
+	depends on ACPI_HOTPLUG
+	default m
+	help
+	  ACPI system device hotplug slot is an abstraction of ACPI based
+	  system device dynamic reconfiguration control points. On load,
+	  this driver enumerates system device hotplug slots by wakling the
+	  ACPI namespace and provides platform specific methods to control
+	  those hotplug slots.
+
+	  By default, this driver detects system device hotplug slots by
+	  checking avaliability of ACPI _EJ0 method. You may pass a module
+	  parameter "fake_slot=0xf" to enable faking hotplug slots on
+	  platforms without hardware dynamic reconfiguration capabilities.
+
+	  To compile this driver as a module, choose M here:
+	  the module will be called acpihp_slot.
+
 config ACPI_CONTAINER
 	tristate "Container and Module Devices (EXPERIMENTAL)"
 	depends on EXPERIMENTAL
diff --git a/drivers/acpi/hotplug/Makefile b/drivers/acpi/hotplug/Makefile
index 5e7790f..2cbb03c 100644
--- a/drivers/acpi/hotplug/Makefile
+++ b/drivers/acpi/hotplug/Makefile
@@ -4,3 +4,6 @@
 
 obj-$(CONFIG_ACPI_HOTPLUG)			+= acpihp.o
 acpihp-y					= core.o
+
+obj-$(CONFIG_ACPI_HOTPLUG_SLOT)			+= acpihp_slot.o
+acpihp_slot-y					= slot.o
diff --git a/drivers/acpi/hotplug/slot.c b/drivers/acpi/hotplug/slot.c
new file mode 100644
index 0000000..b76cb16
--- /dev/null
+++ b/drivers/acpi/hotplug/slot.c
@@ -0,0 +1,417 @@
+/*
+ * Copyright (C) 2012 Huawei Tech. Co., Ltd.
+ * Copyright (C) 2012 Jiang Liu <jiang.liu@huawei.com>
+ * Copyright (C) 2012 Gaohuai Han <hangaohuai@huawei.com>
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ */
+
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/acpi.h>
+#include "acpihp.h"
+
+struct acpihp_slot_id {
+	struct list_head node;
+	enum acpihp_slot_type type;
+	unsigned long instance_id;
+};
+
+static LIST_HEAD(slot_list);
+static LIST_HEAD(slot_id_list);
+static struct acpihp_slot_ops *slot_ops_curr;
+
+/*
+ * Platform dependent slot drivers should be sorted in descending order.
+ * The first entry whose init() method returns success will be used.
+ */
+static struct acpihp_slot_ops *slot_ops_array[] = {
+	NULL
+};
+
+static acpi_status __init
+acpihp_slot_get_dev_type(acpi_handle handle, u32 lvl, void *context, void **rv)
+{
+	u32 *tp = (u32 *)rv;
+	acpi_status status = AE_OK;
+	enum acpihp_dev_type type;
+
+	/* Only care about CPU, memory, PCI host bridge and CONTAINER */
+	if (!acpihp_dev_get_type(handle, &type)) {
+		switch (type) {
+		case ACPIHP_DEV_TYPE_CPU:
+			*tp |= 0x0001;
+			status = AE_CTRL_DEPTH;
+			break;
+		case ACPIHP_DEV_TYPE_MEM:
+			*tp |= 0x0002;
+			status = AE_CTRL_DEPTH;
+			break;
+		case ACPIHP_DEV_TYPE_HOST_BRIDGE:
+			*tp |= 0x0004;
+			status = AE_CTRL_DEPTH;
+			break;
+		case ACPIHP_DEV_TYPE_CONTAINER:
+			*tp |= 0x0008;
+			break;
+		default:
+			break;
+		}
+	}
+
+	return status;
+}
+
+static enum acpihp_slot_type __init acpihp_slot_get_type_child(u32 dev_types)
+{
+	BUG_ON(dev_types > 15);
+
+	switch (dev_types) {
+	case 0:
+		/* Generic CONTAINER */
+		return ACPIHP_SLOT_TYPE_COMMON;
+	case 1:
+		/* Physical processor with logical CPUs */
+		return ACPIHP_SLOT_TYPE_CPU;
+	case 2:
+		/* Memory board/box with memory devices */
+		return ACPIHP_SLOT_TYPE_MEM;
+	case 3:
+		/* Physical processor with CPUs and memory controllers */
+		return ACPIHP_SLOT_TYPE_CPU;
+	case 4:
+		/* IO eXtension board/box with IO host bridges */
+		return ACPIHP_SLOT_TYPE_IOX;
+	case 7:
+		/* Physical processor with CPUs, IO host bridges and MCs. */
+		return ACPIHP_SLOT_TYPE_CPU;
+	case 8:
+		/* Generic CONTAINER */
+		return ACPIHP_SLOT_TYPE_COMMON;
+	case 9:
+		/* System board with physical processors */
+		return ACPIHP_SLOT_TYPE_SYSTEM_BOARD;
+	case 11:
+		/* System board with physical processors and memory */
+		return ACPIHP_SLOT_TYPE_SYSTEM_BOARD;
+	case 15:
+		/* Node with processor, memory and IO host bridge */
+		return ACPIHP_SLOT_TYPE_NODE;
+	default:
+		return ACPIHP_SLOT_TYPE_UNKNOWN;
+	}
+}
+
+static enum acpihp_slot_type __init
+acpihp_slot_get_type_self(struct acpihp_slot *slot)
+{
+	enum acpihp_dev_type type;
+
+	if (acpihp_dev_get_type(slot->handle, &type))
+		return ACPIHP_SLOT_TYPE_UNKNOWN;
+
+	switch (type) {
+	case ACPIHP_DEV_TYPE_CPU:
+		/* Logical CPU used in virtualization environment */
+		return ACPIHP_SLOT_TYPE_CPU;
+	case ACPIHP_DEV_TYPE_MEM:
+		/* Memory board with single memory device */
+		return ACPIHP_SLOT_TYPE_MEM;
+	case ACPIHP_DEV_TYPE_HOST_BRIDGE:
+		/* IO eXtension board/box with single IO host bridge */
+		return ACPIHP_SLOT_TYPE_IOX;
+	default:
+		return ACPIHP_SLOT_TYPE_UNKNOWN;
+	}
+}
+
+/*
+ * Generate a meaningful name for a hotplug slot according to types of ACPI
+ * devices which could be attached to the slot.
+ */
+static int __init acpihp_slot_generate_name(struct acpihp_slot *slot)
+{
+	int found = 0;
+	u32 child_types = 0;
+	unsigned long long uid;
+	struct acpihp_slot_id *slot_id;
+
+	/*
+	 * Figure out slot type by checking types of ACPI devices which could
+	 * be attached to the slot.
+	 */
+	slot->type = acpihp_slot_get_type_self(slot);
+	if (slot->type == ACPIHP_SLOT_TYPE_UNKNOWN) {
+		acpi_walk_namespace(ACPI_TYPE_DEVICE, slot->handle,
+				ACPI_UINT32_MAX, acpihp_slot_get_dev_type,
+				NULL, NULL, (void **)&child_types);
+		acpi_walk_namespace(ACPI_TYPE_PROCESSOR, slot->handle,
+				ACPI_UINT32_MAX, acpihp_slot_get_dev_type,
+				NULL, NULL, (void **)&child_types);
+		slot->type = acpihp_slot_get_type_child(child_types);
+	}
+
+	/* Respect firmware settings if ACPI _UID returns a valid value. */
+	if (ACPI_SUCCESS(acpi_evaluate_integer(slot->handle, METHOD_NAME__UID,
+					       NULL, &uid)))
+		goto set_name;
+
+	/* Generate a unique pseudo instance ID */
+	list_for_each_entry(slot_id, &slot_id_list, node)
+		if (slot_id->type == slot->type) {
+			found = 1;
+			break;
+		}
+	if (!found) {
+		slot_id = kzalloc(sizeof(struct acpihp_slot_id), GFP_KERNEL);
+		if (!slot_id) {
+			ACPIHP_SLOT_WARN(slot,
+				"fails to allocate slot instance ID.\n");
+			return -ENOMEM;
+		}
+		slot_id->type = slot->type;
+		list_add_tail(&slot_id->node, &slot_id_list);
+	}
+	uid = slot_id->instance_id++;
+
+set_name:
+	snprintf(slot->name, sizeof(slot->name) - 1, "%s%02llx",
+		 acpihp_get_slot_type_name(slot->type), uid);
+	dev_set_name(&slot->dev, "%s", slot->name);
+
+	return 0;
+}
+
+static int __init acpihp_slot_get_parent(struct acpihp_slot *slot)
+{
+	acpi_handle handle, root_handle;
+	struct acpihp_slot *tmp;
+
+	slot->parent = NULL;
+	handle = slot->handle;
+	if (ACPI_FAILURE(acpi_get_handle(NULL, ACPI_NS_ROOT_PATH,
+					 &root_handle))) {
+		ACPIHP_SLOT_DEBUG(slot, "fails to get ACPI root device.\n");
+		return -ENODEV;
+	}
+
+	do {
+		if (ACPI_FAILURE(acpi_get_parent(handle, &handle))) {
+			ACPIHP_SLOT_DEBUG(slot,
+					  "fails to get parent device.\n");
+			return -ENODEV;
+		}
+		list_for_each_entry(tmp, &slot_list, slot_list)
+			if (tmp->handle == handle) {
+				slot->parent = tmp;
+				return 0;
+			}
+	} while (handle != root_handle);
+
+	return 0;
+}
+
+static int __init acpihp_slot_get_state(struct acpihp_slot *slot)
+{
+	unsigned long long sta;
+
+	/* Hotplug slots must implement ACPI _STA method. */
+	if (ACPI_FAILURE(acpihp_slot_get_status(slot, &sta))) {
+		ACPIHP_SLOT_DEBUG(slot, "fails to execute _STA method.\n");
+		return -EINVAL;
+	}
+
+	if (!(sta & ACPI_STA_DEVICE_PRESENT))
+		slot->state = ACPIHP_SLOT_STATE_ABSENT;
+	else if ((sta & ACPI_STA_DEVICE_ENABLED) ||
+		 (sta & ACPI_STA_DEVICE_FUNCTIONING))
+		slot->state = ACPIHP_SLOT_STATE_POWERED;
+	else
+		slot->state = ACPIHP_SLOT_STATE_PRESENT;
+
+	return 0;
+}
+
+static int __init acpihp_slot_create(acpi_handle handle)
+{
+	struct acpihp_slot *slot;
+
+	slot = acpihp_alloc_slot(handle, NULL);
+	if (!slot) {
+		ACPIHP_DEBUG("fails to allocate memory for slot %p.\n", handle);
+		return -ENOMEM;
+	}
+
+	slot->slot_ops = slot_ops_curr;
+	if (ACPI_FAILURE(slot_ops_curr->create(slot))) {
+		ACPIHP_DEBUG("fails to create slot for %p.\n", handle);
+		goto out_free;
+	}
+	if (acpihp_slot_get_parent(slot))
+		goto out_destroy;
+	if (acpihp_slot_get_state(slot))
+		goto out_destroy;
+	if (acpihp_slot_generate_name(slot))
+		goto out_destroy;
+
+	if (acpihp_register_slot(slot)) {
+		ACPIHP_SLOT_DEBUG(slot, "fails to register slot.\n");
+		goto out_destroy;
+	}
+	if (ACPI_FAILURE(acpihp_mark_slot(handle, slot))) {
+		ACPIHP_SLOT_DEBUG(slot,
+			"fails to attach slot to ACPI device object.\n");
+		goto out_unregister;
+	}
+
+	list_add_tail(&slot->slot_list, &slot_list);
+
+	return 0;
+
+out_unregister:
+	acpihp_unregister_slot(slot);
+out_destroy:
+	if (slot_ops_curr->destroy)
+		slot_ops_curr->destroy(slot);
+out_free:
+	acpihp_slot_put(slot);
+	return -ENODEV;
+}
+
+static acpi_status __init acpihp_slot_scan(acpi_handle handle, u32 lvl,
+					   void *context, void **rv)
+{
+	enum acpihp_dev_type type;
+
+	if (acpihp_dev_get_type(handle, &type) ||
+	    type == ACPIHP_DEV_TYPE_UNKNOWN)
+		return AE_OK;
+
+	if (ACPI_SUCCESS(slot_ops_curr->check(handle)))
+		acpihp_slot_create(handle);
+
+	/*
+	 * Don't scan hotplug slots under PCI host bridges, they should be
+	 * handled by acpiphp or pciehp drivers.
+	 */
+	if (type == ACPIHP_DEV_TYPE_HOST_BRIDGE)
+		return AE_CTRL_DEPTH;
+
+	return AE_OK;
+}
+
+static int __init acpihp_slot_scan_slots(void)
+{
+	acpi_status status;
+
+	status = acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
+				     ACPI_UINT32_MAX, acpihp_slot_scan,
+				     NULL, NULL, NULL);
+	if (!ACPI_SUCCESS(status))
+		goto out_err;
+
+	status = acpi_walk_namespace(ACPI_TYPE_PROCESSOR, ACPI_ROOT_OBJECT,
+				     ACPI_UINT32_MAX, acpihp_slot_scan,
+				     NULL, NULL, NULL);
+	if (ACPI_SUCCESS(status))
+		return 0;
+
+out_err:
+	ACPIHP_DEBUG("fails to scan ACPI hotplug slots.\n");
+
+	return -ENODEV;
+}
+
+static void acpihp_slot_cleanup(void)
+{
+	struct acpihp_slot *slot, *tmp;
+	struct acpihp_slot_id *slot_id, *tmp_id;
+
+	list_for_each_entry_safe(slot, tmp, &slot_list, slot_list) {
+		acpihp_unmark_slot(slot->handle);
+		acpihp_unregister_slot(slot);
+		if (slot->slot_ops && slot->slot_ops->destroy)
+			slot->slot_ops->destroy(slot);
+		acpihp_slot_put(slot);
+	}
+
+	list_for_each_entry_safe(slot_id, tmp_id, &slot_id_list, node) {
+		list_del(&slot_id->node);
+		kfree(slot_id);
+	}
+}
+
+static int __init acpihp_slot_init(void)
+{
+	int i, retval;
+
+	/* probe for available platform specific slot driver. */
+	for (i = 0; slot_ops_array[i]; i++)
+		if (ACPI_SUCCESS(slot_ops_array[i]->init())) {
+			slot_ops_curr = slot_ops_array[i];
+			break;
+		}
+	if (slot_ops_curr == NULL) {
+		ACPIHP_DEBUG("no platform specific slot driver available.\n");
+		return -ENODEV;
+	}
+
+	retval = acpihp_core_init();
+	if (retval != 0) {
+		ACPIHP_DEBUG("fails to initialize ACPIHP core.\n");
+		goto out_fini;
+	}
+
+	if (acpihp_slot_scan_slots() != 0)
+		ACPIHP_DEBUG("fails to enumerate ACPI hotplug slots.\n");
+
+	/* Back out if no ACPI hotplug slot found. */
+	if (list_empty(&slot_list)) {
+		ACPIHP_DEBUG("no ACPI hotplug slot available.\n");
+		retval = -ENODEV;
+		goto out_core_fini;
+	}
+
+	return 0;
+
+out_core_fini:
+	acpihp_core_fini();
+out_fini:
+	if (slot_ops_curr && slot_ops_curr->fini)
+		slot_ops_curr->fini();
+	ACPIHP_DEBUG("fails to initialize ACPI hotplug slot driver.\n");
+
+	return retval;
+}
+
+static void __exit acpihp_slot_exit(void)
+{
+	acpihp_slot_cleanup();
+	acpihp_core_fini();
+	if (slot_ops_curr && slot_ops_curr->fini)
+		slot_ops_curr->fini();
+}
+
+module_init(acpihp_slot_init);
+module_exit(acpihp_slot_exit);
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Jiang Liu <jiang.liu@huawei.com>");
+MODULE_AUTHOR("Gaohuai Han <hangaohuai@huawei.com>");
-- 
1.7.9.5

[ACPIHP PATCH part1 3/4] ACPIHP: detect ACPI hotplug slots by checking ACPI _EJ0 method

[Jiang Liu]

This patch implements a default mechanism to detect and manage ACPI
system device hotplug slots based on standard ACPI interfaces.
1) Detech hotplug slot by checking existence of _EJ0 and _STA methods.
2) Power off a slot by evaluating _EJ0 method.

It's the default hotplug slot enumerating mechanism, platform specifc
drivers may provide advanced implementation to override the default
implementation.

Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Signed-off-by: Gaohuai Han <hangaohuai@huawei.com>
---
 drivers/acpi/hotplug/Makefile   |    1 +
 drivers/acpi/hotplug/acpihp.h   |    1 +
 drivers/acpi/hotplug/slot.c     |    1 +
 drivers/acpi/hotplug/slot_ej0.c |  143 +++++++++++++++++++++++++++++++++++++++
 4 files changed, 146 insertions(+)
 create mode 100644 drivers/acpi/hotplug/slot_ej0.c

diff --git a/drivers/acpi/hotplug/Makefile b/drivers/acpi/hotplug/Makefile
index 2cbb03c..5420ae7 100644
--- a/drivers/acpi/hotplug/Makefile
+++ b/drivers/acpi/hotplug/Makefile
@@ -7,3 +7,4 @@ acpihp-y					= core.o
 
 obj-$(CONFIG_ACPI_HOTPLUG_SLOT)			+= acpihp_slot.o
 acpihp_slot-y					= slot.o
+acpihp_slot-y					+= slot_ej0.o
diff --git a/drivers/acpi/hotplug/acpihp.h b/drivers/acpi/hotplug/acpihp.h
index 7467895..278c8c2 100644
--- a/drivers/acpi/hotplug/acpihp.h
+++ b/drivers/acpi/hotplug/acpihp.h
@@ -28,5 +28,6 @@
 #include <acpi/acpi_hotplug.h>
 
 extern struct acpi_device *acpi_root;
+extern struct acpihp_slot_ops acpihp_slot_ej0;
 
 #endif
diff --git a/drivers/acpi/hotplug/slot.c b/drivers/acpi/hotplug/slot.c
index b76cb16..e5861fc 100644
--- a/drivers/acpi/hotplug/slot.c
+++ b/drivers/acpi/hotplug/slot.c
@@ -43,6 +43,7 @@ static struct acpihp_slot_ops *slot_ops_curr;
  * The first entry whose init() method returns success will be used.
  */
 static struct acpihp_slot_ops *slot_ops_array[] = {
+	&acpihp_slot_ej0,
 	NULL
 };
 
diff --git a/drivers/acpi/hotplug/slot_ej0.c b/drivers/acpi/hotplug/slot_ej0.c
new file mode 100644
index 0000000..fa987dc
--- /dev/null
+++ b/drivers/acpi/hotplug/slot_ej0.c
@@ -0,0 +1,143 @@
+/*
+ * Copyright (C) 2012 Huawei Tech. Co., Ltd.
+ * Copyright (C) 2012 Gaohuai Han <hangaohuai@huawei.com>
+ * Copyright (C) 2012 Jiang Liu <jiang.liu@huawei.com>
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or (at
+ *  your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful, but
+ *  WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with this program.
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ */
+
+#include <linux/acpi.h>
+#include <acpi/acpi.h>
+#include <acpi/acpi_hotplug.h>
+
+static acpi_status acpihp_slot_ej0_capable(acpi_handle handle)
+{
+	acpi_handle tmp;
+
+	/* Assume a device object with _EJ0 and _STA is a hotplug slot. */
+	if (ACPI_FAILURE(acpi_get_handle(handle, "_EJ0", &tmp)))
+		return AE_ERROR;
+	if (ACPI_FAILURE(acpi_get_handle(handle, METHOD_NAME__STA, &tmp)))
+		return AE_ERROR;
+
+	return AE_OK;
+}
+
+static acpi_status
+acpihp_slot_ej0_check(acpi_handle handle, u32 lvl, void *context, void **rv)
+{
+	acpi_status rc = AE_OK;
+	enum acpihp_dev_type type;
+
+	if (!acpihp_dev_get_type(handle, &type)) {
+		switch (type) {
+		case ACPIHP_DEV_TYPE_CPU:
+		case ACPIHP_DEV_TYPE_MEM:
+		case ACPIHP_DEV_TYPE_HOST_BRIDGE:
+		case ACPIHP_DEV_TYPE_CONTAINER:
+			if (ACPI_SUCCESS(acpihp_slot_ej0_capable(handle))) {
+				*(int *)rv = 1;
+				rc = AE_CTRL_TERMINATE;
+			} else if (type == ACPIHP_DEV_TYPE_HOST_BRIDGE) {
+				rc = AE_CTRL_DEPTH;
+			}
+			break;
+		default:
+			break;
+		}
+	}
+
+	return rc;
+}
+
+static acpi_status acpihp_slot_ej0_init(void)
+{
+	int cap = 0;
+
+	acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
+			ACPI_UINT32_MAX, acpihp_slot_ej0_check,
+			NULL, NULL, (void **)&cap);
+	acpi_walk_namespace(ACPI_TYPE_PROCESSOR, ACPI_ROOT_OBJECT,
+			ACPI_UINT32_MAX, acpihp_slot_ej0_check,
+			NULL, NULL, (void **)&cap);
+
+	return cap ? AE_OK : AE_ERROR;
+}
+
+static acpi_status acpihp_slot_ej0_create(struct acpihp_slot *slot)
+{
+	/*
+	 * Assume device objects with _EJ0 are capable of:
+	 * ONLINE, OFFLINE, POWEROFF, HOTPLUG
+	 */
+	slot->capabilities = ACPIHP_SLOT_CAP_ONLINE | ACPIHP_SLOT_CAP_OFFLINE |
+			     ACPIHP_SLOT_CAP_POWEROFF | ACPIHP_SLOT_CAP_HOTPLUG;
+
+	return AE_OK;
+}
+
+static acpi_status acpihp_slot_ej0_poweroff(struct acpihp_slot *slot)
+{
+	acpi_status status;
+	unsigned long long sta;
+	union acpi_object arg;
+	struct acpi_object_list arg_list;
+	acpi_handle handle = slot->handle;
+	acpi_handle dummy_handle;
+
+	if (ACPI_SUCCESS(acpi_get_handle(handle, "_PS3", &dummy_handle))) {
+		status = acpi_evaluate_object(handle, "_PS3", NULL, NULL);
+		if (ACPI_FAILURE(status)) {
+			ACPIHP_SLOT_DEBUG(slot, "fails to evaluate _PS3.\n");
+			return status;
+		}
+	}
+
+	arg_list.count = 1;
+	arg_list.pointer = &arg;
+	arg.type = ACPI_TYPE_INTEGER;
+	arg.integer.value = 1;
+	status = acpi_evaluate_object(handle, "_EJ0", &arg_list, NULL);
+	if (ACPI_FAILURE(status)) {
+		ACPIHP_SLOT_WARN(slot, "fails to power off.\n");
+		return status;
+	}
+
+	status = acpi_evaluate_integer(handle, METHOD_NAME__STA, NULL, &sta);
+	if (ACPI_FAILURE(status)) {
+		ACPIHP_SLOT_WARN(slot, "fails to evaluate _STA method\n");
+		return status;
+	}
+
+	if (sta & (ACPI_STA_DEVICE_FUNCTIONING | ACPI_STA_DEVICE_ENABLED)) {
+		ACPIHP_SLOT_WARN(slot,
+			 "object is still active after executing _EJ0.\n");
+		return AE_ERROR;
+	}
+
+	return AE_OK;
+}
+
+struct acpihp_slot_ops acpihp_slot_ej0 = {
+	.owner = THIS_MODULE,
+	.desc = "Control Hotplug Slots by ACPI _EJ0 Method",
+	.init = acpihp_slot_ej0_init,
+	.check = acpihp_slot_ej0_capable,
+	.create = acpihp_slot_ej0_create,
+	.poweroff = acpihp_slot_ej0_poweroff,
+};
-- 
1.7.9.5

[ACPIHP PATCH part1 4/4] ACPIHP: implement a fake ACPI system device hotplug slot enumerator

[Jiang Liu]

This patch implements a fake ACPI system device hotplug slot enumerator,
which could be used to test and verify hotplug logic on platforms with
hardware hotplug capabilities.

The fake slot enumerator will be enabled by passing module parameter
"fake_slot=value". The encoding of "value" is:
0x1: fake ACPI CONTAINER device as hotplug slot
0x2: fake ACPI memory device as hotplug slot
0x4: fake ACPI Processor object or Processor device as hotplug slot
0x8: fake ACPI PCI host bridge device as hotplug slot.

Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
---
 drivers/acpi/Kconfig             |   10 +++
 drivers/acpi/hotplug/Makefile    |    1 +
 drivers/acpi/hotplug/acpihp.h    |    3 +
 drivers/acpi/hotplug/slot.c      |    3 +
 drivers/acpi/hotplug/slot_fake.c |  180 ++++++++++++++++++++++++++++++++++++++
 5 files changed, 197 insertions(+)
 create mode 100644 drivers/acpi/hotplug/slot_fake.c

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index af0aaf6..4d15b49 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -353,6 +353,16 @@ config ACPI_HOTPLUG_SLOT
 	  To compile this driver as a module, choose M here:
 	  the module will be called acpihp_slot.
 
+config ACPI_HOTPLUG_SLOT_FAKE
+	bool "Fake Hotplug Slots"
+	depends on ACPI_HOTPLUG_SLOT
+	default n
+	help
+	  This options enables a method to fake system device hotplug slots
+	  on hardware platforms without dynamic reconfiguration capabilities.
+
+	  Pass parameter "fake_slot=0xf" to enable this function.
+
 config ACPI_CONTAINER
 	tristate "Container and Module Devices (EXPERIMENTAL)"
 	depends on EXPERIMENTAL
diff --git a/drivers/acpi/hotplug/Makefile b/drivers/acpi/hotplug/Makefile
index 5420ae7..c19b350 100644
--- a/drivers/acpi/hotplug/Makefile
+++ b/drivers/acpi/hotplug/Makefile
@@ -8,3 +8,4 @@ acpihp-y					= core.o
 obj-$(CONFIG_ACPI_HOTPLUG_SLOT)			+= acpihp_slot.o
 acpihp_slot-y					= slot.o
 acpihp_slot-y					+= slot_ej0.o
+acpihp_slot-$(CONFIG_ACPI_HOTPLUG_SLOT_FAKE)	+= slot_fake.o
diff --git a/drivers/acpi/hotplug/acpihp.h b/drivers/acpi/hotplug/acpihp.h
index 278c8c2..7c49eab 100644
--- a/drivers/acpi/hotplug/acpihp.h
+++ b/drivers/acpi/hotplug/acpihp.h
@@ -29,5 +29,8 @@
 
 extern struct acpi_device *acpi_root;
 extern struct acpihp_slot_ops acpihp_slot_ej0;
+#ifdef	CONFIG_ACPI_HOTPLUG_SLOT_FAKE
+extern struct acpihp_slot_ops acpihp_slot_fake;
+#endif
 
 #endif
diff --git a/drivers/acpi/hotplug/slot.c b/drivers/acpi/hotplug/slot.c
index e5861fc..b72523d 100644
--- a/drivers/acpi/hotplug/slot.c
+++ b/drivers/acpi/hotplug/slot.c
@@ -44,6 +44,9 @@ static struct acpihp_slot_ops *slot_ops_curr;
  */
 static struct acpihp_slot_ops *slot_ops_array[] = {
 	&acpihp_slot_ej0,
+#ifdef	CONFIG_ACPI_HOTPLUG_SLOT_FAKE
+	&acpihp_slot_fake,
+#endif
 	NULL
 };
 
diff --git a/drivers/acpi/hotplug/slot_fake.c b/drivers/acpi/hotplug/slot_fake.c
new file mode 100644
index 0000000..e70243a
--- /dev/null
+++ b/drivers/acpi/hotplug/slot_fake.c
@@ -0,0 +1,180 @@
+/*
+ * Copyright (C) 2012 Huawei Tech. Co., Ltd.
+ * Copyright (C) 2012 Jiang Liu <jiang.liu@huawei.com>
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or (at
+ *  your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful, but
+ *  WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with this program.
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ */
+
+#include <linux/acpi.h>
+#include <acpi/acpi.h>
+#include <acpi/acpi_hotplug.h>
+#include "acpihp.h"
+
+struct acpihp_slot_fake_data {
+	bool enabled;
+};
+
+/*
+ * Encoding of the fake_slot parameter:
+ * 0x1: fake ACPI CONTAINER device as hotplug slot
+ * 0x2: fake ACPI memory device as hotplug slot
+ * 0x4: fake ACPI Processor object or Processor device as hotplug slot
+ * 0x8: fake ACPI PCI host bridge device as hotplug slot.
+ * The above encoding must be kept in consistence with definition of
+ * 'enum acpihp_dev_type'.
+ */
+int acpihp_fake_slot;
+module_param_named(fake_slot, acpihp_fake_slot, int, S_IRUGO);
+MODULE_PARM_DESC(fake_slot, "fake ACPI hotplug slots");
+
+static acpi_status acpihp_slot_fake_init(void)
+{
+	return acpihp_fake_slot ? AE_OK : AE_ERROR;
+}
+
+static acpi_status
+acpihp_slot_fake_check(acpi_handle handle, u32 lvl, void *context, void **rv)
+{
+	int *valid = (int *)rv;
+	enum acpihp_dev_type type;
+
+	if (!acpihp_dev_get_type(handle, &type)) {
+		switch (type) {
+		case ACPIHP_DEV_TYPE_CPU:
+		case ACPIHP_DEV_TYPE_MEM:
+		case ACPIHP_DEV_TYPE_HOST_BRIDGE:
+			*valid = 1;
+			return AE_CTRL_TERMINATE;
+		default:
+			break;
+		}
+	}
+
+	return AE_OK;
+}
+
+static acpi_status acpihp_slot_fake_capable(acpi_handle handle)
+{
+	int valid = 0;
+	acpi_status rc;
+	unsigned long long sta;
+	enum acpihp_dev_type type;
+
+	/* Only care about CPU, memory, PCI host bridge and CONTAINER */
+	if (acpihp_dev_get_type(handle, &type))
+		return AE_ERROR;
+	if (type == ACPIHP_DEV_TYPE_CPU || type == ACPIHP_DEV_TYPE_MEM ||
+	    type == ACPIHP_DEV_TYPE_HOST_BRIDGE) {
+		if (acpihp_fake_slot & (1 << (type - 1)))
+			valid = 1;
+	} else if (type == ACPIHP_DEV_TYPE_CONTAINER &&
+		   acpihp_fake_slot & (1 << (type - 1))) {
+		acpi_walk_namespace(ACPI_TYPE_DEVICE, handle,
+				ACPI_UINT32_MAX, acpihp_slot_fake_check,
+				NULL, NULL, (void **)&valid);
+		acpi_walk_namespace(ACPI_TYPE_PROCESSOR, handle,
+				ACPI_UINT32_MAX, acpihp_slot_fake_check,
+				NULL, NULL, (void **)&valid);
+	}
+	if (valid == 0)
+		return AE_ERROR;
+
+	/* Check whether device is present and enabled. */
+	rc = acpi_evaluate_integer(handle, "_STA", NULL, &sta);
+	if (rc == AE_NOT_FOUND)
+		sta = ACPI_STA_DEVICE_PRESENT | ACPI_STA_DEVICE_ENABLED;
+	else if (ACPI_FAILURE(rc))
+		sta = 0;
+	else if (sta & ACPI_STA_DEVICE_FUNCTIONING)
+		sta |= ACPI_STA_DEVICE_PRESENT | ACPI_STA_DEVICE_ENABLED;
+	if (!(sta & ACPI_STA_DEVICE_PRESENT) ||
+	    !(sta & ACPI_STA_DEVICE_ENABLED))
+		return AE_ERROR;
+
+	return AE_OK;
+}
+
+static acpi_status acpihp_slot_fake_create(struct acpihp_slot *slot)
+{
+	struct acpihp_slot_fake_data *data;
+
+	data = kzalloc(sizeof(*data), GFP_KERNEL);
+	if (!data)
+		return AE_ERROR;
+
+	data->enabled = true;
+	slot->slot_data = data;
+	slot->capabilities = ACPIHP_SLOT_CAP_POWERON |
+			     ACPIHP_SLOT_CAP_POWEROFF |
+			     ACPIHP_SLOT_CAP_ONLINE |
+			     ACPIHP_SLOT_CAP_OFFLINE;
+
+	return AE_OK;
+}
+
+static void acpihp_slot_fake_destroy(struct acpihp_slot *slot)
+{
+	struct acpihp_slot_fake_data *data = slot->slot_data;
+
+	slot->slot_data = NULL;
+	kfree(data);
+}
+
+static acpi_status
+acpihp_slot_fake_get_status(struct acpihp_slot *slot, u64 *status)
+{
+	struct acpihp_slot_fake_data *data = slot->slot_data;
+
+	if (data->enabled)
+		*status = ACPI_STA_DEVICE_PRESENT | ACPI_STA_DEVICE_ENABLED |
+			  ACPI_STA_DEVICE_FUNCTIONING;
+	else
+		*status = ACPI_STA_DEVICE_PRESENT;
+
+	return AE_OK;
+}
+
+static acpi_status acpihp_slot_fake_poweron(struct acpihp_slot *slot)
+{
+	struct acpihp_slot_fake_data *data = slot->slot_data;
+
+	data->enabled = true;
+
+	return AE_OK;
+}
+
+static acpi_status acpihp_slot_fake_poweroff(struct acpihp_slot *slot)
+{
+	struct acpihp_slot_fake_data *data = slot->slot_data;
+
+	data->enabled = false;
+
+	return AE_OK;
+}
+
+struct acpihp_slot_ops acpihp_slot_fake = {
+	.owner = THIS_MODULE,
+	.desc = "Fake Hotplug Slot Enumerator for Testing",
+	.init = acpihp_slot_fake_init,
+	.check = acpihp_slot_fake_capable,
+	.create = acpihp_slot_fake_create,
+	.destroy = acpihp_slot_fake_destroy,
+	.poweron = acpihp_slot_fake_poweron,
+	.poweroff = acpihp_slot_fake_poweroff,
+	.get_status = acpihp_slot_fake_get_status,
+};
-- 
1.7.9.5

Re: [ACPIHP PATCH part1 1/4] ACPIHP: introduce a framework for ACPI based system device hotplug

[Bjorn Helgaas]

On Sat, Nov 3, 2012 at 10:07 AM, Jiang Liu <liuj97@gmail.com> wrote:
> Modern high-end servers may support advanced RAS features, such as
> system device dynamic reconfiguration. On x86 and IA64 platforms,
> system device means processor(CPU), memory device, PCI host bridge
> and even computer node.
>
> The ACPI specifications have provided standard interfaces between
> firmware and OS to support device dynamic reconfiguraiton at runtime.
> This patch series introduces a new framework for system device
> dynamic reconfiguration based on ACPI specification, which will
> replace current existing system device hotplug logic embedded in
> ACPI processor/memory/container device drivers.
>
> The new ACPI based hotplug framework is modelled after the PCI hotplug
> architecture and target to achieve following goals:
> 1) Optimize device configuration order to achieve best performance for
>    hot-added system devices. For best perforamnce, system device should
>    be configured in order of memory -> CPU -> IOAPIC/IOMMU -> PCI HB.
> 2) Resolve dependencies among hotplug slots. You need first to remove
>    the memory device before removing a physical processor if a
>    hotpluggable memory device is connected to a hotpluggable physical
>    processor.

Doesn't the namespace already have a way to communicate these dependencies?

> 3) Provide interface to cancel ongoing hotplug operations. It may take
>    a very long time to remove a memory device, so provide interface to
>    cancel the inprogress hotplug operations.
> 4) Support new advanced RAS features, such as socket/memory migration.
> 5) Provide better user interfaces to access the hotplug functionalities.
> 6) Provide a mechanism to detect hotplug slots by checking existence
>    of ACPI _EJ0 method or by other hardware platform specific methods.

I don't know what "hotplug slot" means for ACPI.  ACPI allows hotplug
of arbitrary devices in the namespace, whether they have EJ0 or not.

> 7) Unify the way to enumerate ACPI based hotplug slots. All hotplug
>    slots will be enumerated by the enumeration driver (acpihp_slot),
>    instead of by individual ACPI device drivers.

Why do we need to enumerate these "slots" specifically?

I think this patch adds things in /sys.  It might help if you
described what they are.

> 8) Unify the way to handle ACPI hotplug events. All ACPI hotplug events
>    for system devices will be handled by a generic ACPI hotplug driver
>    (acpihp_drv) instead of by individual ACPI device drivers.
> 9) Provide better error handling and error recovery.
> 10) Trigger hotplug events/operations by software. This feature is useful
>    for hardware fault management and/or power saving.
>
> The new framework is composed up of three major components:
> 1) A system device hotplug slot enumerator driver, which enumerates
>    hotplug slots in the system and provides platform specific methods
>    to control those slots.
> 2) A system device hotplug driver, which is a platform independent
>    driver to manage all hotplug slots created by the slot enumerator.
>    The hotplug driver implements a state machine for hotplug slots and
>    provides user interfaces to manage hotplug slots.
> 3) Several ACPI device drivers to configure/unconfigure system devices
>    at runtime.
>
> To get rid of inter dependengcy between the slot enumerator and hotplug
> driver, common code shared by them will be built into the kernel. The
> shared code provides some helper routines and a device class named
> acpihp_slot_class with following default sysfs properties:
>         capabilities: RAS capabilities of the hotplug slot
>         state: current state of the hotplug slot state machine
>         status: current health status of the hotplug slot
>         object: ACPI object corresponding to the hotplug slot
>
> Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
> Signed-off-by: Gaohuai Han <hangaohuai@huawei.com>

...
> +static char *acpihp_dev_mem_ids[] = {
> +       "PNP0C80",
> +       NULL
> +};
> +
> +static char *acpihp_dev_pcihb_ids[] = {
> +       "PNP0A03",
> +       NULL
> +};

Why should this driver need to know about these PNP IDs?  We ought to
be able to support hotplug of any device in the namespace, no matter
what its ID.

Re: [ACPIHP PATCH part1 2/4] ACPIHP: introduce acpihp_slot driver to enumerate hotplug slots

[Bjorn Helgaas]

On Sat, Nov 3, 2012 at 10:07 AM, Jiang Liu <liuj97@gmail.com> wrote:
> An ACPI hotplug slot is an abstraction of receptacles, where a group of
> system devices could be connected to. This patch implements the skeleton
> of the ACPI system device hotplug slot enumerator. On loading, it scans
> the whole ACPI namespace for hotplug slots and creates a device node for
> each hotplug slot found. Every hotplug slot is associated with a device
> class named acpihp_slot_class. Later hotplug drivers will register onto
> acpihp_slot_class to manage all hotplug slots.
>
> Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
> Signed-off-by: Gaohuai Han <hangaohuai@huawei.com>
> ---
>  drivers/acpi/Kconfig          |   19 ++
>  drivers/acpi/hotplug/Makefile |    3 +
>  drivers/acpi/hotplug/slot.c   |  417 +++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 439 insertions(+)
>  create mode 100644 drivers/acpi/hotplug/slot.c
>
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index 9577b23..af0aaf6 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -334,6 +334,25 @@ menuconfig ACPI_HOTPLUG
>           If your hardware platform does not support system device dynamic
>           reconfiguration at runtime, you need not to enable this option.
>
> +config ACPI_HOTPLUG_SLOT
> +       tristate "System Device Hotplug Slot Enumerator"

I don't really believe in hotplug drivers being modules.  I think the
core should support hotplug directly, and the decision to configure or
not should be made at build-time.

> +       depends on ACPI_HOTPLUG
> +       default m
> +       help
> +         ACPI system device hotplug slot is an abstraction of ACPI based
> +         system device dynamic reconfiguration control points. On load,
> +         this driver enumerates system device hotplug slots by wakling the
> +         ACPI namespace and provides platform specific methods to control
> +         those hotplug slots.
> +
> +         By default, this driver detects system device hotplug slots by
> +         checking avaliability of ACPI _EJ0 method. You may pass a module
> +         parameter "fake_slot=0xf" to enable faking hotplug slots on
> +         platforms without hardware dynamic reconfiguration capabilities.
> +
> +         To compile this driver as a module, choose M here:
> +         the module will be called acpihp_slot.
> +

> +static int __init acpihp_slot_generate_name(struct acpihp_slot *slot)
> +{
> +       int found = 0;
> +       u32 child_types = 0;
> +       unsigned long long uid;
> +       struct acpihp_slot_id *slot_id;
> +
> +       /*
> +        * Figure out slot type by checking types of ACPI devices which could
> +        * be attached to the slot.
> +        */
> +       slot->type = acpihp_slot_get_type_self(slot);
> +       if (slot->type == ACPIHP_SLOT_TYPE_UNKNOWN) {
> +               acpi_walk_namespace(ACPI_TYPE_DEVICE, slot->handle,
> +                               ACPI_UINT32_MAX, acpihp_slot_get_dev_type,
> +                               NULL, NULL, (void **)&child_types);
> +               acpi_walk_namespace(ACPI_TYPE_PROCESSOR, slot->handle,
> +                               ACPI_UINT32_MAX, acpihp_slot_get_dev_type,
> +                               NULL, NULL, (void **)&child_types);
> +               slot->type = acpihp_slot_get_type_child(child_types);
> +       }

If things can be hot-added below slot->handle, is there an ACPI
requirement that there be *anything* in the existing namespace below
slot->handle?  I'm not sure you can tell sort of things might be
added.

> +static int __init acpihp_slot_scan_slots(void)
> +{
> +       acpi_status status;
> +
> +       status = acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
> +                                    ACPI_UINT32_MAX, acpihp_slot_scan,
> +                                    NULL, NULL, NULL);
> +       if (!ACPI_SUCCESS(status))
> +               goto out_err;
> +
> +       status = acpi_walk_namespace(ACPI_TYPE_PROCESSOR, ACPI_ROOT_OBJECT,
> +                                    ACPI_UINT32_MAX, acpihp_slot_scan,
> +                                    NULL, NULL, NULL);

Here's one reason I don't like this as a module: we have to walk the
namespace again (twice, even).  What happens when you hot-add a node
that itself *contains* another hot-pluggable receptacle?  Do you walk
the namespace again, calling acpiphp_slot_scan() as needed?

Re: [ACPIHP PATCH part1 1/4] ACPIHP: introduce a framework for ACPI based system device hotplug

[Jiang Liu]

Hi Bjorn,
	Thanks for your review and please refer to inlined comments below.

On 11/06/2012 05:05 AM, Bjorn Helgaas wrote:
> On Sat, Nov 3, 2012 at 10:07 AM, Jiang Liu <liuj97@gmail.com> wrote:
>> Modern high-end servers may support advanced RAS features, such as
>> system device dynamic reconfiguration. On x86 and IA64 platforms,
>> system device means processor(CPU), memory device, PCI host bridge
>> and even computer node.
>>
>> The ACPI specifications have provided standard interfaces between
>> firmware and OS to support device dynamic reconfiguraiton at runtime.
>> This patch series introduces a new framework for system device
>> dynamic reconfiguration based on ACPI specification, which will
>> replace current existing system device hotplug logic embedded in
>> ACPI processor/memory/container device drivers.
>>
>> The new ACPI based hotplug framework is modelled after the PCI hotplug
>> architecture and target to achieve following goals:
>> 1) Optimize device configuration order to achieve best performance for
>>    hot-added system devices. For best perforamnce, system device should
>>    be configured in order of memory -> CPU -> IOAPIC/IOMMU -> PCI HB.
>> 2) Resolve dependencies among hotplug slots. You need first to remove
>>    the memory device before removing a physical processor if a
>>    hotpluggable memory device is connected to a hotpluggable physical
>>    processor.
> 
> Doesn't the namespace already have a way to communicate these dependencies?
The namespace could could resolve most dependency issues, but there are still
several corner cases need special care.
1) On a typical Intel Nehalem/Westmere platform, an IOH will be connected to
two physical processors through QPI. The IOH depends on the two processors.
And the ACPI namespace is something like:
/_SB
    |_SCK0
    |_SCK1
    |_PCI1
2) For a large system composed up of multiple computer nodes, nodes may have
dependency on neighbors due to interconnect topology constraints.

So we need to resolve dependency by both evaluating _EDL and analyze ACPI
namespace topology.

>> 3) Provide interface to cancel ongoing hotplug operations. It may take
>>    a very long time to remove a memory device, so provide interface to
>>    cancel the inprogress hotplug operations.
>> 4) Support new advanced RAS features, such as socket/memory migration.
>> 5) Provide better user interfaces to access the hotplug functionalities.
>> 6) Provide a mechanism to detect hotplug slots by checking existence
>>    of ACPI _EJ0 method or by other hardware platform specific methods.
> 
> I don't know what "hotplug slot" means for ACPI.  ACPI allows hotplug
> of arbitrary devices in the namespace, whether they have EJ0 or not.
Here "hotplug" slot is an abstraction of receptacles where a group of
system devices could be attached to, or where we could control a group
of system devices. It's totally conceptual, may or may not has 
corresponding physical slots. For example,
1) a hotplug slot for a hotpluggable memory board has a physical slot.
2) a hotplug slot for a non-hotpluggable processor with power control
capability has no physical slot. (That means you may power on/off a
physical processor but can't hotplug it at runtime). This case is useful
for hardware partitioning.

Detecting hotplug slots by checking existence of _EJ0 is the default
but unreliable way. For a real high-end server with system device
hotplug capabilities should provide some static ACPI table to describe
hotplug slots/capabilities. There are some ongoing efforts for that from
Intel, but not in the public domain yet. So the hotplug slot enumeration
driver is designed to extensible:)

>> 7) Unify the way to enumerate ACPI based hotplug slots. All hotplug
>>    slots will be enumerated by the enumeration driver (acpihp_slot),
>>    instead of by individual ACPI device drivers.
> 
> Why do we need to enumerate these "slots" specifically?
> 
> I think this patch adds things in /sys.  It might help if you
> described what they are.
There's no standard way in ACPI5.0 to describe system device hotplug slots yet.
And we want to show user the system device hotplug capabilities even when there
is no device attached to a slot. In other word, user could now how much
devices they could connect to the system by hotplugging.

>> 8) Unify the way to handle ACPI hotplug events. All ACPI hotplug events
>>    for system devices will be handled by a generic ACPI hotplug driver
>>    (acpihp_drv) instead of by individual ACPI device drivers.
>> 9) Provide better error handling and error recovery.
>> 10) Trigger hotplug events/operations by software. This feature is useful
>>    for hardware fault management and/or power saving.
>>
>> The new framework is composed up of three major components:
>> 1) A system device hotplug slot enumerator driver, which enumerates
>>    hotplug slots in the system and provides platform specific methods
>>    to control those slots.
>> 2) A system device hotplug driver, which is a platform independent
>>    driver to manage all hotplug slots created by the slot enumerator.
>>    The hotplug driver implements a state machine for hotplug slots and
>>    provides user interfaces to manage hotplug slots.
>> 3) Several ACPI device drivers to configure/unconfigure system devices
>>    at runtime.
>>
>> To get rid of inter dependengcy between the slot enumerator and hotplug
>> driver, common code shared by them will be built into the kernel. The
>> shared code provides some helper routines and a device class named
>> acpihp_slot_class with following default sysfs properties:
>>         capabilities: RAS capabilities of the hotplug slot
>>         state: current state of the hotplug slot state machine
>>         status: current health status of the hotplug slot
>>         object: ACPI object corresponding to the hotplug slot
>>
>> Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
>> Signed-off-by: Gaohuai Han <hangaohuai@huawei.com>
> 
> ...
>> +static char *acpihp_dev_mem_ids[] = {
>> +       "PNP0C80",
>> +       NULL
>> +};
>> +
>> +static char *acpihp_dev_pcihb_ids[] = {
>> +       "PNP0A03",
>> +       NULL
>> +};
> 
> Why should this driver need to know about these PNP IDs?  We ought to
> be able to support hotplug of any device in the namespace, no matter
> what its ID.
We need PNP IDs for:
1) Give a meaningful name for each slot.
lrwxrwxrwx  CPU00 -> ../../../devices/LNXSYSTM:00/acpihp/CPU00
lrwxrwxrwx  CPU01 -> ../../../devices/LNXSYSTM:00/acpihp/CPU01
lrwxrwxrwx  CPU02 -> ../../../devices/LNXSYSTM:00/acpihp/CPU02
lrwxrwxrwx  CPU03 -> ../../../devices/LNXSYSTM:00/acpihp/CPU03
lrwxrwxrwx  IOX01 -> ../../../devices/LNXSYSTM:00/acpihp/IOX01
lrwxrwxrwx  MEM00 -> ../../../devices/LNXSYSTM:00/acpihp/CPU00/MEM00
lrwxrwxrwx  MEM01 -> ../../../devices/LNXSYSTM:00/acpihp/CPU00/MEM01
lrwxrwxrwx  MEM02 -> ../../../devices/LNXSYSTM:00/acpihp/CPU01/MEM02
lrwxrwxrwx  MEM03 -> ../../../devices/LNXSYSTM:00/acpihp/CPU01/MEM03
lrwxrwxrwx  MEM04 -> ../../../devices/LNXSYSTM:00/acpihp/CPU02/MEM04
lrwxrwxrwx  MEM05 -> ../../../devices/LNXSYSTM:00/acpihp/CPU02/MEM05
lrwxrwxrwx  MEM06 -> ../../../devices/LNXSYSTM:00/acpihp/CPU03/MEM06
lrwxrwxrwx  MEM07 -> ../../../devices/LNXSYSTM:00/acpihp/CPU03/MEM07

2) Classify system device into groups according to device types, so we could
configure/unconfigure them in optimal order for performance as:
memory -> CPU -> IOAPIC -> PCI host bridge

3) The new hotplug framework are designed to handle system device hotplug,
and it won't hand IO device hotplug such as PCI etc. So it need to stop
scanning subtree of PCI host bridges.

Thanks!
Gerry

Re: [ACPIHP PATCH part1 2/4] ACPIHP: introduce acpihp_slot driver to enumerate hotplug slots

[Jiang Liu]

On 11/06/2012 05:30 AM, Bjorn Helgaas wrote:
> On Sat, Nov 3, 2012 at 10:07 AM, Jiang Liu <liuj97@gmail.com> wrote:
>> An ACPI hotplug slot is an abstraction of receptacles, where a group of
>> system devices could be connected to. This patch implements the skeleton
>> of the ACPI system device hotplug slot enumerator. On loading, it scans
>> the whole ACPI namespace for hotplug slots and creates a device node for
>> each hotplug slot found. Every hotplug slot is associated with a device
>> class named acpihp_slot_class. Later hotplug drivers will register onto
>> acpihp_slot_class to manage all hotplug slots.
>>
>> Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
>> Signed-off-by: Gaohuai Han <hangaohuai@huawei.com>
>> ---
>>  drivers/acpi/Kconfig          |   19 ++
>>  drivers/acpi/hotplug/Makefile |    3 +
>>  drivers/acpi/hotplug/slot.c   |  417 +++++++++++++++++++++++++++++++++++++++++
>>  3 files changed, 439 insertions(+)
>>  create mode 100644 drivers/acpi/hotplug/slot.c
>>
>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>> index 9577b23..af0aaf6 100644
>> --- a/drivers/acpi/Kconfig
>> +++ b/drivers/acpi/Kconfig
>> @@ -334,6 +334,25 @@ menuconfig ACPI_HOTPLUG
>>           If your hardware platform does not support system device dynamic
>>           reconfiguration at runtime, you need not to enable this option.
>>
>> +config ACPI_HOTPLUG_SLOT
>> +       tristate "System Device Hotplug Slot Enumerator"
> 
> I don't really believe in hotplug drivers being modules.  I think the
> core should support hotplug directly, and the decision to configure or
> not should be made at build-time.
Good suggestion, I will change it in next version.

>> +       depends on ACPI_HOTPLUG
>> +       default m
>> +       help
>> +         ACPI system device hotplug slot is an abstraction of ACPI based
>> +         system device dynamic reconfiguration control points. On load,
>> +         this driver enumerates system device hotplug slots by wakling the
>> +         ACPI namespace and provides platform specific methods to control
>> +         those hotplug slots.
>> +
>> +         By default, this driver detects system device hotplug slots by
>> +         checking avaliability of ACPI _EJ0 method. You may pass a module
>> +         parameter "fake_slot=0xf" to enable faking hotplug slots on
>> +         platforms without hardware dynamic reconfiguration capabilities.
>> +
>> +         To compile this driver as a module, choose M here:
>> +         the module will be called acpihp_slot.
>> +
> 
>> +static int __init acpihp_slot_generate_name(struct acpihp_slot *slot)
>> +{
>> +       int found = 0;
>> +       u32 child_types = 0;
>> +       unsigned long long uid;
>> +       struct acpihp_slot_id *slot_id;
>> +
>> +       /*
>> +        * Figure out slot type by checking types of ACPI devices which could
>> +        * be attached to the slot.
>> +        */
>> +       slot->type = acpihp_slot_get_type_self(slot);
>> +       if (slot->type == ACPIHP_SLOT_TYPE_UNKNOWN) {
>> +               acpi_walk_namespace(ACPI_TYPE_DEVICE, slot->handle,
>> +                               ACPI_UINT32_MAX, acpihp_slot_get_dev_type,
>> +                               NULL, NULL, (void **)&child_types);
>> +               acpi_walk_namespace(ACPI_TYPE_PROCESSOR, slot->handle,
>> +                               ACPI_UINT32_MAX, acpihp_slot_get_dev_type,
>> +                               NULL, NULL, (void **)&child_types);
>> +               slot->type = acpihp_slot_get_type_child(child_types);
>> +       }
> 
> If things can be hot-added below slot->handle, is there an ACPI
> requirement that there be *anything* in the existing namespace below
> slot->handle?  I'm not sure you can tell sort of things might be
> added.
To be compatible with old Windows, some BIOS will expose such a behavior.
It put the PCI root bus built in a physical processor directly under /_SB
instead of the module device for the processor. According to my observation,
new BIOSes have changed that behavior and build ACPI namespace according to
physical topology. 

>> +static int __init acpihp_slot_scan_slots(void)
>> +{
>> +       acpi_status status;
>> +
>> +       status = acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
>> +                                    ACPI_UINT32_MAX, acpihp_slot_scan,
>> +                                    NULL, NULL, NULL);
>> +       if (!ACPI_SUCCESS(status))
>> +               goto out_err;
>> +
>> +       status = acpi_walk_namespace(ACPI_TYPE_PROCESSOR, ACPI_ROOT_OBJECT,
>> +                                    ACPI_UINT32_MAX, acpihp_slot_scan,
>> +                                    NULL, NULL, NULL);
> 
> Here's one reason I don't like this as a module: we have to walk the
> namespace again (twice, even).  What happens when you hot-add a node
> that itself *contains* another hot-pluggable receptacle?  Do you walk
> the namespace again, calling acpiphp_slot_scan() as needed?
Loading of dynamic ACPI table is an issue, it should be handled. But we have
left that on the TODO list for simplicity at first stage. When supporting 
that in future, we just need to scan the subtree starting from the slot.

Thanks
Gerry

Re: [ACPIHP PATCH part1 0/4] introduce a framework for ACPI based system device hotplug

[Rafael J. Wysocki]

Hi,

On Sunday, November 04, 2012 12:07:41 AM Jiang Liu wrote:
> Modern high-end servers may support advanced RAS features, such as
> system device dynamic reconfiguration. On x86 and IA64 platforms,
> system device means processor(CPU), memory device, PCI host bridge
> and even computer node.
> 
> The ACPI specifications have provided standard interfaces between
> firmware and OS to support device dynamic reconfiguraiton at runtime.
> This patch series introduces a new framework for system device
> dynamic reconfiguration based on ACPI specification, which will
> replace current existing system device hotplug logic embedded in
> ACPI processor/memory/container device drivers.
> 
> The new ACPI based hotplug framework is modelled after the PCI hotplug
> architecture and target to achieve following goals:
> 1) Optimize device configuration order to achieve best performance for
>    hot-added system devices. For best perforamnce, system device should
>    be configured in order of memory -> CPU -> IOAPIC/IOMMU -> PCI HB.
> 2) Resolve dependencies among hotplug slots. You need first to remove
>    the memory device before removing a physical processor if a
>    hotpluggable memory device is connected to a hotpluggable physical
>    processor.
> 3) Provide interface to cancel ongoing hotplug operations. It may take
>    a very long time to remove a memory device, so provide interface to
>    cancel the inprogress hotplug operations.
> 4) Support new advanced RAS features, such as socket/memory migration.
> 5) Provide better user interfaces to access the hotplug functionalities.
> 6) Provide a mechanism to detect hotplug slots by checking existence
>    of ACPI _EJ0 method or by other hardware platform specific methods.
> 7) Unify the way to enumerate ACPI based hotplug slots. All hotplug
>    slots will be enumerated by the enumeration driver (acpihp_slot),
>    instead of by individual ACPI device drivers.
> 8) Unify the way to handle ACPI hotplug events. All ACPI hotplug events
>    for system devices will be handled by a generic ACPI hotplug driver
>    (acpihp_drv) instead of by individual ACPI device drivers.
> 9) Provide better error handling and error recovery.
> 10) Trigger hotplug events/operations by software. This feature is useful
>    for hardware fault management and/or power saving.
> 
> The new framework is composed up of three major components:
> 1) A system device hotplug slot enumerator driver, which enumerates
>    hotplug slots in the system and provides platform specific methods
>    to control those slots.
> 2) A system device hotplug driver, which is a platform independent
>    driver to manage all hotplug slots created by the slot enumerator.
>    The hotplug driver implements a state machine for hotplug slots and
>    provides user interfaces to manage hotplug slots.
> 3) Several ACPI device drivers to configure/unconfigure system devices
>    at runtime.
> 
> And the whole patchset will be split into 7 parts:
> 1) the hotplug slot enumeration driver (acpihp_slot)
> 2) the system device hotplug driver (acpihp_drv)
> 3) enhance ACPI container driver to support new framework
> 4) enhance ACPI processor driver to support new framework
> 5) enhance ACPI memory driver to support new framework
> 6) enhance ACPI host bridge driver to support new framework
> 7) enhancments and cleanups to the ACPI core

First of all, thanks for following my suggestion and splitting the patchset
into smaller pieces.  It is appreciated.

That said, I still have a problem even with this small part of your original
patchset, because I'm practically unable to assess its possible impact on
future development at the moment.  At least not by myself.

My background is power management and I don't have much experience with
the kind of systems your patchset is targeted at, so I'd need quite a lot
of time to understand the details of your approach and all of the possible
ways it may interfere with the other people's work in progress.  It may just
be the best thing we can do for the use cases you are after, but we also may
be able to address them in simpler ways (which would be better).  Adding new
frameworks like this is not usual in the ACPI subsystem, so to speak, so my
first question is if you considered any alternatives and if you did, then what
they were and why you decided that they would be less suitable.

Moreover, as I'm sure you know, some groups have been working on features
related to your patchset, like memory hotplug, CPU hotplug and PCI host bridge
hotplug, and they have made some progress already.  I wonder, then, in what way
your patchset is going to affect their work.  Is it simply going to make their
lifes easier in all aspects, or (if applied) will it require them to redesign
their code and redo some patchsets they already have tested and queued up
for submission, or, worse yet, will it invalidate their work entirely?  I have
no good answer to this question right now, so I'd like to here from these
people what they think about your work.

Bjorn has already posted his comments and he seems to be skeptical.  His
opinions are very important to me, because he has a lot of experience and
knows things I'm not aware of.  This means, in particular, that I'll be
extremely cautious about applying patches that he has objections against.

You also need to be aware of the fact that some core kernel developers have
long-term goals.  They need not be very precisely defined plans, but just
things those developers would like to achieve at one point in the future.  My
personal goal is to unify the handling of devices by the ACPI subsystem, as
outlined in this message to Yinghai:

http://marc.info/?l=linux-kernel&m=135180467616074&w=4

Unfortunately, I can't really say at this point how your patches, if applied,
will affect this goal (most likely they will make it more difficult to achieve,
it seems) and I know, for example, that the driver core people have some goals
that may be affected by it too (for example, adding new device classes is not
recommended).  That needs to be determined.

Last, but not least, core kernel developers are extremely cautious about adding
new user space interfaces, because doing that is a long-term commitment to
support them and maintain their compatibility with the previous versions.  This
sometimes turns out to be particularly painful, especially if such "old"
interfaces are not suitable for some "new" use cases.  Therefore, every time
somebody wants to add a new sysfs file, for example, we want to know whether
or not this is really necessary/useful and we need to figure out whether or not
the interface being added is the best one for the given use case (and possibly
for other related use cases, including future ones that can be anticipated).
Your patchset seems to add a number of these and they aren't sufficiently
documented, so it is quite difficult to do that.

As for more specific comments, I'd like the changelog of [1/4] to describe
what this particular patch is doing and why it is doing that instead of just
repeating the [0/4] message in its greater part, which isn't very useful.
Also, I'd like sysfs interfaces to be documented in the usual way (i.e. in
Documentation/ABI/) and all functions that are not static to have kerneldoc
comments explaining the meaning of their arguments and describing what the
functions are for (in general terms).  [It wouldn't really hurt if at least
the more important static functions had kerneldoc comments too.]  New data
types, if any, need to be described in comments too (what they are for in
general as well as their individual fields).  It also would be good to have
a general document describing they way the framework is supposed to work under
Documentation/acpi.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: [ACPIHP PATCH part1 1/4] ACPIHP: introduce a framework for ACPI based system device hotplug

[Rafael J. Wysocki]

Hi,

On Wednesday, November 07, 2012 12:18:07 AM Jiang Liu wrote:
> Hi Bjorn,
> 	Thanks for your review and please refer to inlined comments below.
> 
> On 11/06/2012 05:05 AM, Bjorn Helgaas wrote:
> > On Sat, Nov 3, 2012 at 10:07 AM, Jiang Liu <liuj97@gmail.com> wrote:
> >> Modern high-end servers may support advanced RAS features, such as
> >> system device dynamic reconfiguration. On x86 and IA64 platforms,
> >> system device means processor(CPU), memory device, PCI host bridge
> >> and even computer node.
> >>
> >> The ACPI specifications have provided standard interfaces between
> >> firmware and OS to support device dynamic reconfiguraiton at runtime.
> >> This patch series introduces a new framework for system device
> >> dynamic reconfiguration based on ACPI specification, which will
> >> replace current existing system device hotplug logic embedded in
> >> ACPI processor/memory/container device drivers.
> >>
> >> The new ACPI based hotplug framework is modelled after the PCI hotplug
> >> architecture and target to achieve following goals:
> >> 1) Optimize device configuration order to achieve best performance for
> >>    hot-added system devices. For best perforamnce, system device should
> >>    be configured in order of memory -> CPU -> IOAPIC/IOMMU -> PCI HB.
> >> 2) Resolve dependencies among hotplug slots. You need first to remove
> >>    the memory device before removing a physical processor if a
> >>    hotpluggable memory device is connected to a hotpluggable physical
> >>    processor.
> > 
> > Doesn't the namespace already have a way to communicate these dependencies?

> The namespace could could resolve most dependency issues, but there are still
> several corner cases need special care.
> 1) On a typical Intel Nehalem/Westmere platform, an IOH will be connected to
> two physical processors through QPI. The IOH depends on the two processors.
> And the ACPI namespace is something like:
> /_SB
>     |_SCK0
>     |_SCK1
>     |_PCI1
> 2) For a large system composed up of multiple computer nodes, nodes may have
> dependency on neighbors due to interconnect topology constraints.
> 
> So we need to resolve dependency by both evaluating _EDL and analyze ACPI
> namespace topology.

Well, this doesn't explain why we need a new framework.

> >> 3) Provide interface to cancel ongoing hotplug operations. It may take
> >>    a very long time to remove a memory device, so provide interface to
> >>    cancel the inprogress hotplug operations.
> >> 4) Support new advanced RAS features, such as socket/memory migration.
> >> 5) Provide better user interfaces to access the hotplug functionalities.
> >> 6) Provide a mechanism to detect hotplug slots by checking existence
> >>    of ACPI _EJ0 method or by other hardware platform specific methods.
> > 
> > I don't know what "hotplug slot" means for ACPI.  ACPI allows hotplug
> > of arbitrary devices in the namespace, whether they have EJ0 or not.

> Here "hotplug" slot is an abstraction of receptacles where a group of
> system devices could be attached to, or where we could control a group
> of system devices. It's totally conceptual, may or may not has 
> corresponding physical slots.

Can that be called something different from "slot", then, to avoid confusion?

> For example,
> 1) a hotplug slot for a hotpluggable memory board has a physical slot.

So let's call that a "slot" and the abstraction above a "hotplug domain" or
something similar.  Because in fact we're talking about hotplug domains,
aren't we?

> 2) a hotplug slot for a non-hotpluggable processor with power control
> capability has no physical slot. (That means you may power on/off a
> physical processor but can't hotplug it at runtime). This case is useful
> for hardware partitioning.

People have been working on this particular thing for years, so I wonder
why you think that your apprach is going to be better here?

> Detecting hotplug slots by checking existence of _EJ0 is the default
> but unreliable way. For a real high-end server with system device
> hotplug capabilities should provide some static ACPI table to describe
> hotplug slots/capabilities. There are some ongoing efforts for that from
> Intel, but not in the public domain yet. So the hotplug slot enumeration
> driver is designed to extensible:)
> 
> >> 7) Unify the way to enumerate ACPI based hotplug slots. All hotplug
> >>    slots will be enumerated by the enumeration driver (acpihp_slot),
> >>    instead of by individual ACPI device drivers.
> > 
> > Why do we need to enumerate these "slots" specifically?
> > 
> > I think this patch adds things in /sys.  It might help if you
> > described what they are.

> There's no standard way in ACPI5.0 to describe system device hotplug slots yet.
> And we want to show user the system device hotplug capabilities even when there
> is no device attached to a slot. In other word, user could now how much
> devices they could connect to the system by hotplugging.

Bjorn probably meant "provide documentation describing the user space interfaces
being introduced".  Which in fact is a requirement.

> >> 8) Unify the way to handle ACPI hotplug events. All ACPI hotplug events
> >>    for system devices will be handled by a generic ACPI hotplug driver
> >>    (acpihp_drv) instead of by individual ACPI device drivers.
> >> 9) Provide better error handling and error recovery.
> >> 10) Trigger hotplug events/operations by software. This feature is useful
> >>    for hardware fault management and/or power saving.
> >>
> >> The new framework is composed up of three major components:
> >> 1) A system device hotplug slot enumerator driver, which enumerates
> >>    hotplug slots in the system and provides platform specific methods
> >>    to control those slots.
> >> 2) A system device hotplug driver, which is a platform independent
> >>    driver to manage all hotplug slots created by the slot enumerator.
> >>    The hotplug driver implements a state machine for hotplug slots and
> >>    provides user interfaces to manage hotplug slots.
> >> 3) Several ACPI device drivers to configure/unconfigure system devices
> >>    at runtime.
> >>
> >> To get rid of inter dependengcy between the slot enumerator and hotplug
> >> driver, common code shared by them will be built into the kernel. The
> >> shared code provides some helper routines and a device class named
> >> acpihp_slot_class with following default sysfs properties:
> >>         capabilities: RAS capabilities of the hotplug slot
> >>         state: current state of the hotplug slot state machine
> >>         status: current health status of the hotplug slot
> >>         object: ACPI object corresponding to the hotplug slot
> >>
> >> Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
> >> Signed-off-by: Gaohuai Han <hangaohuai@huawei.com>
> > 
> > ...
> >> +static char *acpihp_dev_mem_ids[] = {
> >> +       "PNP0C80",
> >> +       NULL
> >> +};
> >> +
> >> +static char *acpihp_dev_pcihb_ids[] = {
> >> +       "PNP0A03",
> >> +       NULL
> >> +};
> > 
> > Why should this driver need to know about these PNP IDs?  We ought to
> > be able to support hotplug of any device in the namespace, no matter
> > what its ID.

> We need PNP IDs for:
> 1) Give a meaningful name for each slot.
> lrwxrwxrwx  CPU00 -> ../../../devices/LNXSYSTM:00/acpihp/CPU00
> lrwxrwxrwx  CPU01 -> ../../../devices/LNXSYSTM:00/acpihp/CPU01
> lrwxrwxrwx  CPU02 -> ../../../devices/LNXSYSTM:00/acpihp/CPU02
> lrwxrwxrwx  CPU03 -> ../../../devices/LNXSYSTM:00/acpihp/CPU03
> lrwxrwxrwx  IOX01 -> ../../../devices/LNXSYSTM:00/acpihp/IOX01
> lrwxrwxrwx  MEM00 -> ../../../devices/LNXSYSTM:00/acpihp/CPU00/MEM00
> lrwxrwxrwx  MEM01 -> ../../../devices/LNXSYSTM:00/acpihp/CPU00/MEM01
> lrwxrwxrwx  MEM02 -> ../../../devices/LNXSYSTM:00/acpihp/CPU01/MEM02
> lrwxrwxrwx  MEM03 -> ../../../devices/LNXSYSTM:00/acpihp/CPU01/MEM03
> lrwxrwxrwx  MEM04 -> ../../../devices/LNXSYSTM:00/acpihp/CPU02/MEM04
> lrwxrwxrwx  MEM05 -> ../../../devices/LNXSYSTM:00/acpihp/CPU02/MEM05
> lrwxrwxrwx  MEM06 -> ../../../devices/LNXSYSTM:00/acpihp/CPU03/MEM06
> lrwxrwxrwx  MEM07 -> ../../../devices/LNXSYSTM:00/acpihp/CPU03/MEM07
> 
> 2) Classify system device into groups according to device types, so we could
> configure/unconfigure them in optimal order for performance as:
> memory -> CPU -> IOAPIC -> PCI host bridge
> 
> 3) The new hotplug framework are designed to handle system device hotplug,
> and it won't hand IO device hotplug such as PCI etc. So it need to stop
> scanning subtree of PCI host bridges.

Well, we probably need a hotplug domains framework, which the thing you're
proposing seems to be.  However, the question is: Why should it cover "system
devices" only?

To me, it looks like such a framework should cover all hotplug devices in the
system, or at least all ACPI-based hotplug devices.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: [ACPIHP PATCH part1 1/4] ACPIHP: introduce a framework for ACPI based system device hotplug

[Jiang Liu]

Hi Rafael,
	Thanks for your comments! And please refer to inlined comments below.

On 11/19/2012 04:43 PM, Rafael J. Wysocki wrote:
> Hi,
> 
> On Wednesday, November 07, 2012 12:18:07 AM Jiang Liu wrote:
>> Hi Bjorn,
>> 	Thanks for your review and please refer to inlined comments below.
>>
>> On 11/06/2012 05:05 AM, Bjorn Helgaas wrote:
>>> On Sat, Nov 3, 2012 at 10:07 AM, Jiang Liu <liuj97@gmail.com> wrote:
>>>> Modern high-end servers may support advanced RAS features, such as
>>>> system device dynamic reconfiguration. On x86 and IA64 platforms,
>>>> system device means processor(CPU), memory device, PCI host bridge
>>>> and even computer node.
>>>>
>>>> The ACPI specifications have provided standard interfaces between
>>>> firmware and OS to support device dynamic reconfiguraiton at runtime.
>>>> This patch series introduces a new framework for system device
>>>> dynamic reconfiguration based on ACPI specification, which will
>>>> replace current existing system device hotplug logic embedded in
>>>> ACPI processor/memory/container device drivers.
>>>>
>>>> The new ACPI based hotplug framework is modelled after the PCI hotplug
>>>> architecture and target to achieve following goals:
>>>> 1) Optimize device configuration order to achieve best performance for
>>>>    hot-added system devices. For best perforamnce, system device should
>>>>    be configured in order of memory -> CPU -> IOAPIC/IOMMU -> PCI HB.
>>>> 2) Resolve dependencies among hotplug slots. You need first to remove
>>>>    the memory device before removing a physical processor if a
>>>>    hotpluggable memory device is connected to a hotpluggable physical
>>>>    processor.
>>>
>>> Doesn't the namespace already have a way to communicate these dependencies?
> 
>> The namespace could could resolve most dependency issues, but there are still
>> several corner cases need special care.
>> 1) On a typical Intel Nehalem/Westmere platform, an IOH will be connected to
>> two physical processors through QPI. The IOH depends on the two processors.
>> And the ACPI namespace is something like:
>> /_SB
>>     |_SCK0
>>     |_SCK1
>>     |_PCI1
>> 2) For a large system composed up of multiple computer nodes, nodes may have
>> dependency on neighbors due to interconnect topology constraints.
>>
>> So we need to resolve dependency by both evaluating _EDL and analyze ACPI
>> namespace topology.
> 
> Well, this doesn't explain why we need a new framework.
Currently hotplug capable system devices are managed by different ACPI drivers,
such as processor, container and acpi_memhotplug. And these ACPI drivers only
know hotplug-capable devices managed by itself and don't know hotplug-capable
devices managed by other drivers. For example, ACPI processor driver doesn't
know hotplug memory devices. So existing ACPI system device hotplug drivers
don't resolve dependencies at all.

With the new framework, it knows all hotplug domains within the system, and
it will automatically resolves dependencies when changing state of a hotplug
domain. This is very important because hotplug requests may be triggered
concurrently through different mechanism, such pressing the hotplug button,
issued from OS or issued from the OOB system management center. The new
framework will guarantee that all requests are correctly serialized. 

>>>> 3) Provide interface to cancel ongoing hotplug operations. It may take
>>>>    a very long time to remove a memory device, so provide interface to
>>>>    cancel the inprogress hotplug operations.
>>>> 4) Support new advanced RAS features, such as socket/memory migration.
>>>> 5) Provide better user interfaces to access the hotplug functionalities.
>>>> 6) Provide a mechanism to detect hotplug slots by checking existence
>>>>    of ACPI _EJ0 method or by other hardware platform specific methods.
>>>
>>> I don't know what "hotplug slot" means for ACPI.  ACPI allows hotplug
>>> of arbitrary devices in the namespace, whether they have EJ0 or not.
> 
>> Here "hotplug" slot is an abstraction of receptacles where a group of
>> system devices could be attached to, or where we could control a group
>> of system devices. It's totally conceptual, may or may not has 
>> corresponding physical slots.
> 
> Can that be called something different from "slot", then, to avoid confusion?
On some other OSes, it's called "attachment point" or "AP". I use slot
because its used by PCI hotplug. If that causes confusion, we may call
it something else, any suggestion?

>> For example,
>> 1) a hotplug slot for a hotpluggable memory board has a physical slot.
> 
> So let's call that a "slot" and the abstraction above a "hotplug domain" or
> something similar.  Because in fact we're talking about hotplug domains,
> aren't we?
Yeah, maybe "hotplug domain" is a good candidate for "hotplug slot".

>> 2) a hotplug slot for a non-hotpluggable processor with power control
>> capability has no physical slot. (That means you may power on/off a
>> physical processor but can't hotplug it at runtime). This case is useful
>> for hardware partitioning.
> 
> People have been working on this particular thing for years, so I wonder
> why you think that your apprach is going to be better here?
To support hardware partitioning or power management, OS needs to provide
interfaces to control those power-control-capable devices. But currently
we have only interface to power off a device and without interface to
power on a device.

Another benefit of the new framework is to support memory migration. A memory
device may support memory migration but don't support memory hotplug. The
new framework will abstract the migration-capable memory device as a hotplug
domain, so user can manage the memory device.

>> Detecting hotplug slots by checking existence of _EJ0 is the default
>> but unreliable way. For a real high-end server with system device
>> hotplug capabilities should provide some static ACPI table to describe
>> hotplug slots/capabilities. There are some ongoing efforts for that from
>> Intel, but not in the public domain yet. So the hotplug slot enumeration
>> driver is designed to extensible:)
>>
>>>> 7) Unify the way to enumerate ACPI based hotplug slots. All hotplug
>>>>    slots will be enumerated by the enumeration driver (acpihp_slot),
>>>>    instead of by individual ACPI device drivers.
>>>
>>> Why do we need to enumerate these "slots" specifically?
>>>
>>> I think this patch adds things in /sys.  It might help if you
>>> described what they are.
> 
>> There's no standard way in ACPI5.0 to describe system device hotplug slots yet.
>> And we want to show user the system device hotplug capabilities even when there
>> is no device attached to a slot. In other word, user could now how much
>> devices they could connect to the system by hotplugging.
> 
> Bjorn probably meant "provide documentation describing the user space interfaces
> being introduced".  Which in fact is a requirement.
Thanks for reminder. Documentation for sysfs interface is a must, and we have
plan for that. How about providing sysfs interface docs after we have settled
down about the overall idea and design?

>>>> 8) Unify the way to handle ACPI hotplug events. All ACPI hotplug events
>>>>    for system devices will be handled by a generic ACPI hotplug driver
>>>>    (acpihp_drv) instead of by individual ACPI device drivers.
>>>> 9) Provide better error handling and error recovery.
>>>> 10) Trigger hotplug events/operations by software. This feature is useful
>>>>    for hardware fault management and/or power saving.
>>>>
>>>> The new framework is composed up of three major components:
>>>> 1) A system device hotplug slot enumerator driver, which enumerates
>>>>    hotplug slots in the system and provides platform specific methods
>>>>    to control those slots.
>>>> 2) A system device hotplug driver, which is a platform independent
>>>>    driver to manage all hotplug slots created by the slot enumerator.
>>>>    The hotplug driver implements a state machine for hotplug slots and
>>>>    provides user interfaces to manage hotplug slots.
>>>> 3) Several ACPI device drivers to configure/unconfigure system devices
>>>>    at runtime.
>>>>
>>>> To get rid of inter dependengcy between the slot enumerator and hotplug
>>>> driver, common code shared by them will be built into the kernel. The
>>>> shared code provides some helper routines and a device class named
>>>> acpihp_slot_class with following default sysfs properties:
>>>>         capabilities: RAS capabilities of the hotplug slot
>>>>         state: current state of the hotplug slot state machine
>>>>         status: current health status of the hotplug slot
>>>>         object: ACPI object corresponding to the hotplug slot
>>>>
>>>> Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
>>>> Signed-off-by: Gaohuai Han <hangaohuai@huawei.com>
>>>
>>> ...
>>>> +static char *acpihp_dev_mem_ids[] = {
>>>> +       "PNP0C80",
>>>> +       NULL
>>>> +};
>>>> +
>>>> +static char *acpihp_dev_pcihb_ids[] = {
>>>> +       "PNP0A03",
>>>> +       NULL
>>>> +};
>>>
>>> Why should this driver need to know about these PNP IDs?  We ought to
>>> be able to support hotplug of any device in the namespace, no matter
>>> what its ID.
> 
>> We need PNP IDs for:
>> 1) Give a meaningful name for each slot.
>> lrwxrwxrwx  CPU00 -> ../../../devices/LNXSYSTM:00/acpihp/CPU00
>> lrwxrwxrwx  CPU01 -> ../../../devices/LNXSYSTM:00/acpihp/CPU01
>> lrwxrwxrwx  CPU02 -> ../../../devices/LNXSYSTM:00/acpihp/CPU02
>> lrwxrwxrwx  CPU03 -> ../../../devices/LNXSYSTM:00/acpihp/CPU03
>> lrwxrwxrwx  IOX01 -> ../../../devices/LNXSYSTM:00/acpihp/IOX01
>> lrwxrwxrwx  MEM00 -> ../../../devices/LNXSYSTM:00/acpihp/CPU00/MEM00
>> lrwxrwxrwx  MEM01 -> ../../../devices/LNXSYSTM:00/acpihp/CPU00/MEM01
>> lrwxrwxrwx  MEM02 -> ../../../devices/LNXSYSTM:00/acpihp/CPU01/MEM02
>> lrwxrwxrwx  MEM03 -> ../../../devices/LNXSYSTM:00/acpihp/CPU01/MEM03
>> lrwxrwxrwx  MEM04 -> ../../../devices/LNXSYSTM:00/acpihp/CPU02/MEM04
>> lrwxrwxrwx  MEM05 -> ../../../devices/LNXSYSTM:00/acpihp/CPU02/MEM05
>> lrwxrwxrwx  MEM06 -> ../../../devices/LNXSYSTM:00/acpihp/CPU03/MEM06
>> lrwxrwxrwx  MEM07 -> ../../../devices/LNXSYSTM:00/acpihp/CPU03/MEM07
>>
>> 2) Classify system device into groups according to device types, so we could
>> configure/unconfigure them in optimal order for performance as:
>> memory -> CPU -> IOAPIC -> PCI host bridge
>>
>> 3) The new hotplug framework are designed to handle system device hotplug,
>> and it won't hand IO device hotplug such as PCI etc. So it need to stop
>> scanning subtree of PCI host bridges.
> 
> Well, we probably need a hotplug domains framework, which the thing you're
> proposing seems to be.  However, the question is: Why should it cover "system
> devices" only?
> 
> To me, it looks like such a framework should cover all hotplug devices in the
> system, or at least all ACPI-based hotplug devices.
It will be great if we could provide a framework for all types of devices,
including both system devices and IO devices. But when starting the ACPI
based system device hotplug project, we found almost all hotplug capable
IO buses/devices have already provided hotplug support, so we focused
on system device hotplug because it's still incomplete.

According to my experience, it's really convenient if OS could provide a
unified tool/interface to support both system device and io device hotplug,
with consistent commands and outputs. But it's hard to provide a framework
to support both system device and io device hotplug at kernel level.
And an example system's hotplug framework is composed up with:
1) a hotplug driver for each type of devices, such as USB, SCSI, PCI and
   system device.
2) a unified userspace application/interface to support all types of hotplug
   drivers

So with that in mind, we have designed the ACPI based system device hotplug
framework as a hotplug driver for system devices. And we still lack of a 
unified userspace application/interface to support all types of device hotplug.

Thanks
Gerry

Re: [ACPIHP PATCH part1 0/4] introduce a framework for ACPI based system device hotplug

[Jiang Liu]

On 11/16/2012 08:58 PM, Rafael J. Wysocki wrote:
> Hi,
> 
> On Sunday, November 04, 2012 12:07:41 AM Jiang Liu wrote:
>> Modern high-end servers may support advanced RAS features, such as
>> system device dynamic reconfiguration. On x86 and IA64 platforms,
>> system device means processor(CPU), memory device, PCI host bridge
>> and even computer node.
>>
>> The ACPI specifications have provided standard interfaces between
>> firmware and OS to support device dynamic reconfiguraiton at runtime.
>> This patch series introduces a new framework for system device
>> dynamic reconfiguration based on ACPI specification, which will
>> replace current existing system device hotplug logic embedded in
>> ACPI processor/memory/container device drivers.
>>
>> The new ACPI based hotplug framework is modelled after the PCI hotplug
>> architecture and target to achieve following goals:
>> 1) Optimize device configuration order to achieve best performance for
>>    hot-added system devices. For best perforamnce, system device should
>>    be configured in order of memory -> CPU -> IOAPIC/IOMMU -> PCI HB.
>> 2) Resolve dependencies among hotplug slots. You need first to remove
>>    the memory device before removing a physical processor if a
>>    hotpluggable memory device is connected to a hotpluggable physical
>>    processor.
>> 3) Provide interface to cancel ongoing hotplug operations. It may take
>>    a very long time to remove a memory device, so provide interface to
>>    cancel the inprogress hotplug operations.
>> 4) Support new advanced RAS features, such as socket/memory migration.
>> 5) Provide better user interfaces to access the hotplug functionalities.
>> 6) Provide a mechanism to detect hotplug slots by checking existence
>>    of ACPI _EJ0 method or by other hardware platform specific methods.
>> 7) Unify the way to enumerate ACPI based hotplug slots. All hotplug
>>    slots will be enumerated by the enumeration driver (acpihp_slot),
>>    instead of by individual ACPI device drivers.
>> 8) Unify the way to handle ACPI hotplug events. All ACPI hotplug events
>>    for system devices will be handled by a generic ACPI hotplug driver
>>    (acpihp_drv) instead of by individual ACPI device drivers.
>> 9) Provide better error handling and error recovery.
>> 10) Trigger hotplug events/operations by software. This feature is useful
>>    for hardware fault management and/or power saving.
>>
>> The new framework is composed up of three major components:
>> 1) A system device hotplug slot enumerator driver, which enumerates
>>    hotplug slots in the system and provides platform specific methods
>>    to control those slots.
>> 2) A system device hotplug driver, which is a platform independent
>>    driver to manage all hotplug slots created by the slot enumerator.
>>    The hotplug driver implements a state machine for hotplug slots and
>>    provides user interfaces to manage hotplug slots.
>> 3) Several ACPI device drivers to configure/unconfigure system devices
>>    at runtime.
>>
>> And the whole patchset will be split into 7 parts:
>> 1) the hotplug slot enumeration driver (acpihp_slot)
>> 2) the system device hotplug driver (acpihp_drv)
>> 3) enhance ACPI container driver to support new framework
>> 4) enhance ACPI processor driver to support new framework
>> 5) enhance ACPI memory driver to support new framework
>> 6) enhance ACPI host bridge driver to support new framework
>> 7) enhancments and cleanups to the ACPI core
> 
> First of all, thanks for following my suggestion and splitting the patchset
> into smaller pieces.  It is appreciated.
> 
> That said, I still have a problem even with this small part of your original
> patchset, because I'm practically unable to assess its possible impact on
> future development at the moment.  At least not by myself.
> 
> My background is power management and I don't have much experience with
> the kind of systems your patchset is targeted at, so I'd need quite a lot
> of time to understand the details of your approach and all of the possible
> ways it may interfere with the other people's work in progress.  It may just
> be the best thing we can do for the use cases you are after, but we also may
> be able to address them in simpler ways (which would be better).  Adding new
> frameworks like this is not usual in the ACPI subsystem, so to speak, so my
> first question is if you considered any alternatives and if you did, then what
> they were and why you decided that they would be less suitable.
> 
> Moreover, as I'm sure you know, some groups have been working on features
> related to your patchset, like memory hotplug, CPU hotplug and PCI host bridge
> hotplug, and they have made some progress already.  I wonder, then, in what way
> your patchset is going to affect their work.  Is it simply going to make their
> lifes easier in all aspects, or (if applied) will it require them to redesign
> their code and redo some patchsets they already have tested and queued up
> for submission, or, worse yet, will it invalidate their work entirely?  I have
> no good answer to this question right now, so I'd like to here from these
> people what they think about your work.
We have noticed the great interests about system device hotplug in the community,
actually that's a good news for us because we could cooperate together to achieve
the goal.

We have deeply involved in the PCI host bridge hotplug work from Yinghai. We have
submitted some patches to Yinghai and Bjorn related to PCI host bridge, and we have
also integrated Yinghai's work with our new framework and tested it on IA64 and
Xeon platforms. We also have reached an agreement with Yinghai that the new framework
will integrate with the PCI host bridge hotplug work after the PCI part has been
upstreamed. And I think PCi host bridge hotplug work and new hotplug framework
are complementary.

For BSP hotplug from Fenghua, I think we could easily integrate it with the new
framework. We have also cooperated with Fujitsu about the memory hotplug core 
logic (not include the ACPI part), we have already submitted some patches, integrated
and tested some patches from Fujitsu. And we have also had an discussion with
Wen Congyang at China Linux Kernel Developer Forum last month about memory hotplug.
We also have a patchset to integrate memory hotplug with the new framework, but
it's still during internal review and tests.

But for the ACPI part for CPU and memory hotplug enhancements recently posted to
the community, I think they are different solutions with the new framework. I feel
they are lightweight enhancements to existing code with some limitations, but the
new framework is a heavyweight solution with full functionalities and improved
usability. So we may need discussions about the different solutions here:)

We have also noticed memory power management related work from 

> 
> Bjorn has already posted his comments and he seems to be skeptical.  His
> opinions are very important to me, because he has a lot of experience and
> knows things I'm not aware of.  This means, in particular, that I'll be
> extremely cautious about applying patches that he has objections against.
Yeah, we really appreciate comments from Bjorn, and he has profound experiences
in may areas.

> 
> You also need to be aware of the fact that some core kernel developers have
> long-term goals.  They need not be very precisely defined plans, but just
> things those developers would like to achieve at one point in the future.  My
> personal goal is to unify the handling of devices by the ACPI subsystem, as
> outlined in this message to Yinghai:
> 
> http://marc.info/?l=linux-kernel&m=135180467616074&w=4
The idea is great to consolidate ACPI and IO device nodes. It will difinitely
help the IOAPIC driver used in PCI host bridge hotplug because anIOAPIC may be
an ACPI and/or PCI device.

It's a great idea to consolidate ACPI driver with native device driver for
IO devices. But there may be some difference for system devices because system
devices are mostly managed in platform dependent ways. For example, cpu and memory
driver under drivers/base/ only implement platform independent functionalities,
and we even have no platform independent driver for PCI host bridges. That means
we still need special handling for system devices in platform dependent way within
the ACPI world.

If we still have some forms of "ACPI drivers" for system devices, it will be ok
for the new hotplug framework even if we remove the "struct device dev" from 
"struct acpi_device". The change for the hotplug framework to support your new
ACPI OS adapter layer shouldn't be too large.

> 
> Unfortunately, I can't really say at this point how your patches, if applied,
> will affect this goal (most likely they will make it more difficult to achieve,
> it seems) and I know, for example, that the driver core people have some goals
> that may be affected by it too (for example, adding new device classes is not
> recommended).  That needs to be determined.
The reason for device class instead of bus driver is just for simplicity. 
If appreciated, we could change the class driver into a bus driver.

> 
> Last, but not least, core kernel developers are extremely cautious about adding
> new user space interfaces, because doing that is a long-term commitment to
> support them and maintain their compatibility with the previous versions.  This
> sometimes turns out to be particularly painful, especially if such "old"
> interfaces are not suitable for some "new" use cases.  Therefore, every time
> somebody wants to add a new sysfs file, for example, we want to know whether
> or not this is really necessary/useful and we need to figure out whether or not
> the interface being added is the best one for the given use case (and possibly
> for other related use cases, including future ones that can be anticipated).
> Your patchset seems to add a number of these and they aren't sufficiently
> documented, so it is quite difficult to do that.
Yeah, we will enhance the documentations. 

> 
> As for more specific comments, I'd like the changelog of [1/4] to describe
> what this particular patch is doing and why it is doing that instead of just
> repeating the [0/4] message in its greater part, which isn't very useful.
> Also, I'd like sysfs interfaces to be documented in the usual way (i.e. in
> Documentation/ABI/) and all functions that are not static to have kerneldoc
> comments explaining the meaning of their arguments and describing what the
> functions are for (in general terms).  [It wouldn't really hurt if at least
> the more important static functions had kerneldoc comments too.]  New data
> types, if any, need to be described in comments too (what they are for in
> general as well as their individual fields).  It also would be good to have
> a general document describing they way the framework is supposed to work under
> Documentation/acpi.
Thanks for reminder, we will enhance these documentations once we have settled
down about the overall idea and design.

Thanks!
Gerry

> 
> Thanks,
> Rafael
> 
> 

Re: [ACPIHP PATCH part1 0/4] introduce a framework for ACPI based system device hotplug

[Toshi Kani]

> But for the ACPI part for CPU and memory hotplug enhancements recently posted to
> the community, I think they are different solutions with the new framework. I feel
> they are lightweight enhancements to existing code with some limitations, but the
> new framework is a heavyweight solution with full functionalities and improved
> usability. So we may need discussions about the different solutions here:)

Hi Gerry,

Thanks for working on the framework enhancement.  I am still new to
Linux (and learning :), but have extensive background in hot-plug
features on other OS for CPU, Memory, Node, RP and PCI hot-plug support.
So, I basically agree with you that we do need framework enhancement.
However, I think we need phased approach here.  First, we need to make
CPU and Memory hot-plug work under the current framework.  Once we
settle on the basic features, we can then make framework enhancements
without breaking the features.  For CPU hotplug, I also intentionally
minimized the code changes so that the changes could be back-ported to
older kernels being used by distributions.

I will send you more comments after I reviewed your patches (which may
take some time :).

Thanks,
-Toshi