* [RFC PATCH v2 06/12] ACPI: Add ACPI bus hotplug handlers
From: Toshi Kani @ 2013-01-10 23:40 UTC (permalink / raw)
To: rjw, lenb, gregkh, akpm
Cc: linux-s390, Toshi Kani, jiang.liu, wency, linux-mm, yinghai,
linux-kernel, linux-acpi, isimatu.yasuaki, srivatsa.bhat,
guohanjun, bhelgaas, linuxppc-dev
In-Reply-To: <1357861230-29549-1-git-send-email-toshi.kani@hp.com>
Added ACPI bus hotplug handlers. acpi_add_execute() calls
acpi_bus_add() to construct new acpi_device objects for hot-add
operation, and acpi_del_execute() calls acpi_bus_trim() to destruct
them for hot-delete operation. They are also used for rollback
as well.
acpi_del_commit() calls _EJ0 to eject a target object for hot-delete.
acpi_validate_ost() calls _OST to inform FW that a hot-plug operation
completed with error in case of rollback.
Signed-off-by: Toshi Kani <toshi.kani@hp.com>
---
drivers/acpi/bus.c | 133 ++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 133 insertions(+)
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 1f0d457..31a1911 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -42,6 +42,7 @@
#include <acpi/apei.h>
#include <linux/dmi.h>
#include <linux/suspend.h>
+#include <acpi/sys_hotplug.h>
#include "internal.h"
@@ -52,6 +53,9 @@ struct acpi_device *acpi_root;
struct proc_dir_entry *acpi_root_dir;
EXPORT_SYMBOL(acpi_root_dir);
+static int acpi_add_execute(struct shp_request *req, int rollback);
+static int acpi_del_execute(struct shp_request *req, int rollback);
+
#define STRUCT_TO_INT(s) (*((int*)&s))
@@ -859,6 +863,134 @@ static void acpi_bus_notify(acpi_handle handle, u32 type, void *data)
}
/* --------------------------------------------------------------------------
+ Hot-plug Handling
+ -------------------------------------------------------------------------- */
+
+static int acpi_validate_ost(struct shp_request *req, int rollback)
+{
+ /* If hotplug request failed, inform firmware with error */
+ if (rollback && shp_is_hotplug_op(req->operation))
+ (void) acpi_evaluate_hotplug_ost(req->handle, req->event,
+ ACPI_OST_SC_NON_SPECIFIC_FAILURE, NULL);
+
+ return 0;
+}
+
+static int acpi_add_execute(struct shp_request *req, int rollback)
+{
+ acpi_handle handle = (acpi_handle) req->handle;
+ acpi_handle phandle;
+ struct acpi_device *device = NULL;
+ struct acpi_device *pdev;
+ int ret;
+
+ if (rollback)
+ return acpi_del_execute(req, 0);
+
+ /* only handle hot-plug operation */
+ if (!shp_is_hotplug_op(req->operation))
+ return 0;
+
+ if (acpi_get_parent(handle, &phandle))
+ return -ENODEV;
+
+ if (acpi_bus_get_device(phandle, &pdev))
+ return -ENODEV;
+
+ ret = acpi_bus_add(&device, pdev, handle, ACPI_BUS_TYPE_DEVICE);
+
+ return ret;
+}
+
+static int acpi_add_commit(struct shp_request *req, int rollback)
+{
+ /* Inform firmware that the hotplug operation has completed */
+ (void) acpi_evaluate_hotplug_ost(req->handle, req->event,
+ ACPI_OST_SC_SUCCESS, NULL);
+
+ return 0;
+}
+
+static int acpi_del_execute(struct shp_request *req, int rollback)
+{
+ acpi_handle handle = (acpi_handle) req->handle;
+ struct acpi_device *device;
+
+ if (rollback)
+ return acpi_add_execute(req, 0);
+
+ /* only handle hot-plug operation */
+ if (!shp_is_hotplug_op(req->operation))
+ return 0;
+
+ if (acpi_bus_get_device(handle, &device)) {
+ acpi_handle_err(handle, "Failed to obtain device\n");
+ return -EINVAL;
+ }
+
+ if (acpi_bus_trim(device, 1)) {
+ dev_err(&device->dev, "Removing device failed\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int acpi_del_commit(struct shp_request *req, int rollback)
+{
+ acpi_handle handle = (acpi_handle) req->handle;
+ acpi_handle temp;
+ struct acpi_object_list arg_list;
+ union acpi_object arg;
+ acpi_status status;
+
+ /* only handle hot-plug operation */
+ if (!shp_is_hotplug_op(req->operation))
+ return 0;
+
+ /* power off device */
+ status = acpi_evaluate_object(handle, "_PS3", NULL, NULL);
+ if (ACPI_FAILURE(status) && status != AE_NOT_FOUND)
+ acpi_handle_warn(handle, "Power-off device failed\n");
+
+ if (ACPI_SUCCESS(acpi_get_handle(handle, "_LCK", &temp))) {
+ arg_list.count = 1;
+ arg_list.pointer = &arg;
+ arg.type = ACPI_TYPE_INTEGER;
+ arg.integer.value = 0;
+ acpi_evaluate_object(handle, "_LCK", &arg_list, NULL);
+ }
+
+ 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) && (status != AE_NOT_FOUND))
+ acpi_handle_warn(handle, "Eject device failed\n");
+
+ return 0;
+}
+
+static void __init acpi_shp_init(void)
+{
+ shp_register_handler(SHP_ADD_VALIDATE, acpi_validate_ost,
+ SHP_ACPI_BUS_ADD_VALIDATE_ORDER);
+ shp_register_handler(SHP_ADD_EXECUTE, acpi_add_execute,
+ SHP_ACPI_BUS_ADD_EXECUTE_ORDER);
+ shp_register_handler(SHP_ADD_COMMIT, acpi_add_commit,
+ SHP_ACPI_BUS_ADD_COMMIT_ORDER);
+
+ shp_register_handler(SHP_DEL_VALIDATE, acpi_validate_ost,
+ SHP_ACPI_BUS_DEL_VALIDATE_ORDER);
+ shp_register_handler(SHP_DEL_EXECUTE, acpi_del_execute,
+ SHP_ACPI_BUS_DEL_EXECUTE_ORDER);
+ shp_register_handler(SHP_DEL_COMMIT, acpi_del_commit,
+ SHP_ACPI_BUS_DEL_COMMIT_ORDER);
+}
+
+/* --------------------------------------------------------------------------
Initialization/Cleanup
-------------------------------------------------------------------------- */
@@ -1103,6 +1235,7 @@ static int __init acpi_init(void)
acpi_debugfs_init();
acpi_sleep_proc_init();
acpi_wakeup_device_init();
+ acpi_shp_init();
return 0;
}
^ permalink raw reply related
* [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
From: Toshi Kani @ 2013-01-10 23:40 UTC (permalink / raw)
To: rjw, lenb, gregkh, akpm
Cc: linux-s390, Toshi Kani, jiang.liu, wency, linux-mm, yinghai,
linux-kernel, linux-acpi, isimatu.yasuaki, srivatsa.bhat,
guohanjun, bhelgaas, linuxppc-dev
In-Reply-To: <1357861230-29549-1-git-send-email-toshi.kani@hp.com>
Added include/linux/sys_hotplug.h, which defines the system device
hotplug framework interfaces used by the framework itself and
handlers.
The order values define the calling sequence of handlers. For add
execute, the ordering is ACPI->MEM->CPU. Memory is onlined before
CPU so that threads on new CPUs can start using their local memory.
The ordering of the delete execute is symmetric to the add execute.
struct shp_request defines a hot-plug request information. The
device resource information is managed with a list so that a single
request may target to multiple devices.
Signed-off-by: Toshi Kani <toshi.kani@hp.com>
---
include/linux/sys_hotplug.h | 181 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 181 insertions(+)
create mode 100644 include/linux/sys_hotplug.h
diff --git a/include/linux/sys_hotplug.h b/include/linux/sys_hotplug.h
new file mode 100644
index 0000000..86674dd
--- /dev/null
+++ b/include/linux/sys_hotplug.h
@@ -0,0 +1,181 @@
+/*
+ * sys_hotplug.h - System device hot-plug framework
+ *
+ * Copyright (C) 2012 Hewlett-Packard Development Company, L.P.
+ * Toshi Kani <toshi.kani@hp.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef _LINUX_SYS_HOTPLUG_H
+#define _LINUX_SYS_HOTPLUG_H
+
+#include <linux/list.h>
+#include <linux/device.h>
+
+/*
+ * System device hot-plug operation proceeds in the following order.
+ * Validate phase -> Execute phase -> Commit phase
+ *
+ * The order values below define the calling sequence of platform
+ * neutral handlers for each phase in ascending order. The order
+ * values of firmware-specific handlers are defined in sys_hotplug.h
+ * under firmware specific directories.
+ */
+
+/* All order values must be smaller than this value */
+#define SHP_ORDER_MAX 0xffffff
+
+/* Add Validate order values */
+
+/* Add Execute order values */
+#define SHP_MEM_ADD_EXECUTE_ORDER 100
+#define SHP_CPU_ADD_EXECUTE_ORDER 110
+
+/* Add Commit order values */
+
+/* Delete Validate order values */
+#define SHP_CPU_DEL_VALIDATE_ORDER 100
+#define SHP_MEM_DEL_VALIDATE_ORDER 110
+
+/* Delete Execute order values */
+#define SHP_CPU_DEL_EXECUTE_ORDER 10
+#define SHP_MEM_DEL_EXECUTE_ORDER 20
+
+/* Delete Commit order values */
+
+/*
+ * Hot-plug request types
+ */
+#define SHP_REQ_ADD 0x000000
+#define SHP_REQ_DELETE 0x000001
+#define SHP_REQ_MASK 0x0000ff
+
+/*
+ * Hot-plug phase types
+ */
+#define SHP_PH_VALIDATE 0x000000
+#define SHP_PH_EXECUTE 0x000100
+#define SHP_PH_COMMIT 0x000200
+#define SHP_PH_MASK 0x00ff00
+
+/*
+ * Hot-plug operation types
+ */
+#define SHP_OP_HOTPLUG 0x000000
+#define SHP_OP_ONLINE 0x010000
+#define SHP_OP_MASK 0xff0000
+
+/*
+ * Hot-plug phases
+ */
+enum shp_phase {
+ SHP_ADD_VALIDATE = (SHP_REQ_ADD|SHP_PH_VALIDATE),
+ SHP_ADD_EXECUTE = (SHP_REQ_ADD|SHP_PH_EXECUTE),
+ SHP_ADD_COMMIT = (SHP_REQ_ADD|SHP_PH_COMMIT),
+ SHP_DEL_VALIDATE = (SHP_REQ_DELETE|SHP_PH_VALIDATE),
+ SHP_DEL_EXECUTE = (SHP_REQ_DELETE|SHP_PH_EXECUTE),
+ SHP_DEL_COMMIT = (SHP_REQ_DELETE|SHP_PH_COMMIT)
+};
+
+/*
+ * Hot-plug operations
+ */
+enum shp_operation {
+ SHP_HOTPLUG_ADD = (SHP_OP_HOTPLUG|SHP_REQ_ADD),
+ SHP_HOTPLUG_DEL = (SHP_OP_HOTPLUG|SHP_REQ_DELETE),
+ SHP_ONLINE_ADD = (SHP_OP_ONLINE|SHP_REQ_ADD),
+ SHP_ONLINE_DEL = (SHP_OP_ONLINE|SHP_REQ_DELETE)
+};
+
+/*
+ * Hot-plug device classes
+ */
+enum shp_class {
+ SHP_CLS_INVALID = 0,
+ SHP_CLS_CPU = 1,
+ SHP_CLS_MEMORY = 2,
+ SHP_CLS_HOSTBRIDGE = 3,
+ SHP_CLS_CONTAINER = 4,
+};
+
+/*
+ * Hot-plug device information
+ */
+union shp_dev_info {
+ struct shp_cpu {
+ u32 cpu_id;
+ } cpu;
+
+ struct shp_memory {
+ int node;
+ u64 start_addr;
+ u64 length;
+ } mem;
+
+ struct shp_hostbridge {
+ } hb;
+
+ struct shp_node {
+ } node;
+};
+
+struct shp_device {
+ struct list_head list;
+ struct device *device;
+ enum shp_class class;
+ union shp_dev_info info;
+};
+
+/*
+ * Hot-plug request
+ */
+struct shp_request {
+ /* common info */
+ enum shp_operation operation; /* operation */
+
+ /* hot-plug event info: only valid for hot-plug operations */
+ void *handle; /* FW handle */
+ u32 event; /* FW event */
+
+ /* device resource info */
+ struct list_head dev_list; /* shp_device list */
+};
+
+/*
+ * Inline Utility Functions
+ */
+static inline bool shp_is_hotplug_op(enum shp_operation operation)
+{
+ return (operation & SHP_OP_MASK) == SHP_OP_HOTPLUG;
+}
+
+static inline bool shp_is_online_op(enum shp_operation operation)
+{
+ return (operation & SHP_OP_MASK) == SHP_OP_ONLINE;
+}
+
+static inline bool shp_is_add_op(enum shp_operation operation)
+{
+ return (operation & SHP_REQ_MASK) == SHP_REQ_ADD;
+}
+
+static inline bool shp_is_add_phase(enum shp_phase phase)
+{
+ return (phase & SHP_REQ_MASK) == SHP_REQ_ADD;
+}
+
+/*
+ * Externs
+ */
+typedef int (*shp_func)(struct shp_request *req, int rollback);
+extern int shp_register_handler(enum shp_phase phase, shp_func func, u32 order);
+extern int shp_unregister_handler(enum shp_phase phase, shp_func func);
+extern int shp_submit_req(struct shp_request *req);
+extern struct shp_request *shp_alloc_request(enum shp_operation operation);
+extern void shp_add_dev_info(struct shp_request *shp_req,
+ struct shp_device *shp_dev);
+
+#endif /* _LINUX_SYS_HOTPLUG_H */
^ permalink raw reply related
* [RFC PATCH v2 08/12] ACPI: Update processor driver for hotplug framework
From: Toshi Kani @ 2013-01-10 23:40 UTC (permalink / raw)
To: rjw, lenb, gregkh, akpm
Cc: linux-s390, Toshi Kani, jiang.liu, wency, linux-mm, yinghai,
linux-kernel, linux-acpi, isimatu.yasuaki, srivatsa.bhat,
guohanjun, bhelgaas, linuxppc-dev
In-Reply-To: <1357861230-29549-1-git-send-email-toshi.kani@hp.com>
Added acpi_processor_resource() for the .resource() interface,
which sets CPU information to a hotplug request.
Changed acpi_processor_hotplug_notify() to request a hotplug
operation by calling shp_submit_req(). It no longer initiates
hot-add or hot-delete operation by calling acpi_bus_add() or
acpi_bus_hot_remove_device() directly.
acpi_processor_handle_eject() is changed not to call cpu_down()
since .add() / .remove() may not online / offline a device.
Signed-off-by: Toshi Kani <toshi.kani@hp.com>
---
drivers/acpi/processor_driver.c | 150 ++++++++++++++++++---------------------
1 file changed, 70 insertions(+), 80 deletions(-)
diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
index e83311b..f630c2c 100644
--- a/drivers/acpi/processor_driver.c
+++ b/drivers/acpi/processor_driver.c
@@ -57,6 +57,7 @@
#include <acpi/acpi_bus.h>
#include <acpi/acpi_drivers.h>
#include <acpi/processor.h>
+#include <acpi/sys_hotplug.h>
#define PREFIX "ACPI: "
@@ -83,6 +84,8 @@ MODULE_LICENSE("GPL");
static int acpi_processor_add(struct acpi_device *device);
static int acpi_processor_remove(struct acpi_device *device, int type);
static void acpi_processor_notify(struct acpi_device *device, u32 event);
+static int acpi_processor_resource(struct acpi_device *device,
+ struct shp_request *shp_req);
static acpi_status acpi_processor_hotadd_init(struct acpi_processor *pr);
static int acpi_processor_handle_eject(struct acpi_processor *pr);
static int acpi_processor_start(struct acpi_processor *pr);
@@ -105,6 +108,7 @@ static struct acpi_driver acpi_processor_driver = {
.add = acpi_processor_add,
.remove = acpi_processor_remove,
.notify = acpi_processor_notify,
+ .resource = acpi_processor_resource,
},
.drv.pm = &acpi_processor_pm,
};
@@ -649,6 +653,33 @@ free:
return 0;
}
+static int
+acpi_processor_resource(struct acpi_device *device, struct shp_request *shp_req)
+{
+ struct acpi_processor *pr;
+ struct shp_device *shp_dev;
+
+ pr = acpi_driver_data(device);
+ if (!pr) {
+ dev_err(&device->dev, "Driver data missing\n");
+ return -EINVAL;
+ }
+
+ shp_dev = kzalloc(sizeof(*shp_dev), GFP_KERNEL);
+ if (!shp_dev) {
+ dev_err(&device->dev, "Failed to allocate shp_dev\n");
+ return -EINVAL;
+ }
+
+ shp_dev->device = &device->dev;
+ shp_dev->class = SHP_CLS_CPU;
+ shp_dev->info.cpu.cpu_id = pr->id;
+
+ shp_add_dev_info(shp_req, shp_dev);
+
+ return 0;
+}
+
#ifdef CONFIG_ACPI_HOTPLUG_CPU
/****************************************************************************
* Acpi processor hotplug support *
@@ -677,97 +708,68 @@ static int is_processor_present(acpi_handle handle)
return 0;
}
-static
-int acpi_processor_device_add(acpi_handle handle, struct acpi_device **device)
-{
- acpi_handle phandle;
- struct acpi_device *pdev;
-
-
- if (acpi_get_parent(handle, &phandle)) {
- return -ENODEV;
- }
-
- if (acpi_bus_get_device(phandle, &pdev)) {
- return -ENODEV;
- }
-
- if (acpi_bus_add(device, pdev, handle, ACPI_BUS_TYPE_PROCESSOR)) {
- return -ENODEV;
- }
-
- return 0;
-}
-
static void acpi_processor_hotplug_notify(acpi_handle handle,
u32 event, void *data)
{
struct acpi_device *device = NULL;
- struct acpi_eject_event *ej_event = NULL;
+ struct shp_request *shp_req;
+ enum shp_operation shp_op;
u32 ost_code = ACPI_OST_SC_NON_SPECIFIC_FAILURE; /* default */
- int result;
switch (event) {
case ACPI_NOTIFY_BUS_CHECK:
case ACPI_NOTIFY_DEVICE_CHECK:
- ACPI_DEBUG_PRINT((ACPI_DB_INFO,
- "Processor driver received %s event\n",
- (event == ACPI_NOTIFY_BUS_CHECK) ?
- "ACPI_NOTIFY_BUS_CHECK" : "ACPI_NOTIFY_DEVICE_CHECK"));
-
- if (!is_processor_present(handle))
- break;
-
- if (!acpi_bus_get_device(handle, &device))
- break;
+ if (!is_processor_present(handle)) {
+ acpi_handle_err(handle, "Device not enabled\n");
+ goto err;
+ }
- result = acpi_processor_device_add(handle, &device);
- if (result) {
- acpi_handle_err(handle, "Unable to add the device\n");
- break;
+ if (!acpi_bus_get_device(handle, &device)) {
+ acpi_handle_err(handle, "Device added already\n");
+ goto err;
}
- ost_code = ACPI_OST_SC_SUCCESS;
+ shp_op = SHP_HOTPLUG_ADD;
break;
case ACPI_NOTIFY_EJECT_REQUEST:
- ACPI_DEBUG_PRINT((ACPI_DB_INFO,
- "received ACPI_NOTIFY_EJECT_REQUEST\n"));
-
if (acpi_bus_get_device(handle, &device)) {
- acpi_handle_err(handle,
- "Device don't exist, dropping EJECT\n");
- break;
+ acpi_handle_err(handle, "Device not added yet\n");
+ goto err;
}
if (!acpi_driver_data(device)) {
- acpi_handle_err(handle,
- "Driver data is NULL, dropping EJECT\n");
- break;
+ acpi_handle_err(handle, "Driver data missing\n");
+ goto err;
}
- ej_event = kmalloc(sizeof(*ej_event), GFP_KERNEL);
- if (!ej_event) {
- acpi_handle_err(handle, "No memory, dropping EJECT\n");
- break;
- }
-
- ej_event->handle = handle;
- ej_event->event = ACPI_NOTIFY_EJECT_REQUEST;
- acpi_os_hotplug_execute(acpi_bus_hot_remove_device,
- (void *)ej_event);
-
- /* eject is performed asynchronously */
- return;
+ shp_op = SHP_HOTPLUG_DEL;
+ break;
default:
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
"Unsupported event [0x%x]\n", event));
-
- /* non-hotplug event; possibly handled by other handler */
return;
}
- /* Inform firmware that the hotplug operation has completed */
+ shp_req = shp_alloc_request(shp_op);
+ if (!shp_req) {
+ acpi_handle_err(handle, "No memory to request hotplug\n");
+ goto err;
+ }
+
+ shp_req->handle = (void *)handle;
+ shp_req->event = event;
+
+ if (shp_submit_req(shp_req)) {
+ acpi_handle_err(handle, "Failed to request hotplug\n");
+ kfree(shp_req);
+ goto err;
+ }
+
+ return;
+
+err:
+ /* Inform firmware that the hotplug operation completed w/ error */
(void) acpi_evaluate_hotplug_ost(handle, event, ost_code, NULL);
return;
}
@@ -865,25 +867,13 @@ static acpi_status acpi_processor_hotadd_init(struct acpi_processor *pr)
static int acpi_processor_handle_eject(struct acpi_processor *pr)
{
- if (cpu_online(pr->id))
- cpu_down(pr->id);
-
- get_online_cpus();
- /*
- * The cpu might become online again at this point. So we check whether
- * the cpu has been onlined or not. If the cpu became online, it means
- * that someone wants to use the cpu. So acpi_processor_handle_eject()
- * returns -EAGAIN.
- */
- if (unlikely(cpu_online(pr->id))) {
- put_online_cpus();
- pr_warn("Failed to remove CPU %d, because other task "
- "brought the CPU back online\n", pr->id);
- return -EAGAIN;
+ if (cpu_online(pr->id)) {
+ pr_err("ACPI: cpu %d not off-lined\n", pr->id);
+ return -EINVAL;
}
+
arch_unregister_cpu(pr->id);
acpi_unmap_lsapic(pr->id);
- put_online_cpus();
return (0);
}
#else
^ permalink raw reply related
* [RFC PATCH v2 02/12] ACPI: Add sys_hotplug.h for system device hotplug framework
From: Toshi Kani @ 2013-01-10 23:40 UTC (permalink / raw)
To: rjw, lenb, gregkh, akpm
Cc: linux-s390, Toshi Kani, jiang.liu, wency, linux-mm, yinghai,
linux-kernel, linux-acpi, isimatu.yasuaki, srivatsa.bhat,
guohanjun, bhelgaas, linuxppc-dev
In-Reply-To: <1357861230-29549-1-git-send-email-toshi.kani@hp.com>
Added include/acpi/sys_hotplug.h, which is ACPI-specific system
device hotplug header and defines the order values of ACPI-specific
handlers.
Signed-off-by: Toshi Kani <toshi.kani@hp.com>
---
include/acpi/sys_hotplug.h | 48 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 48 insertions(+)
create mode 100644 include/acpi/sys_hotplug.h
diff --git a/include/acpi/sys_hotplug.h b/include/acpi/sys_hotplug.h
new file mode 100644
index 0000000..ad80f61
--- /dev/null
+++ b/include/acpi/sys_hotplug.h
@@ -0,0 +1,48 @@
+/*
+ * sys_hotplug.h - ACPI System device hot-plug framework
+ *
+ * Copyright (C) 2012 Hewlett-Packard Development Company, L.P.
+ * Toshi Kani <toshi.kani@hp.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef _ACPI_SYS_HOTPLUG_H
+#define _ACPI_SYS_HOTPLUG_H
+
+#include <linux/list.h>
+#include <linux/device.h>
+#include <linux/sys_hotplug.h>
+
+/*
+ * System device hot-plug operation proceeds in the following order.
+ * Validate phase -> Execute phase -> Commit phase
+ *
+ * The order values below define the calling sequence of ACPI-specific
+ * handlers for each phase in ascending order. The order value of
+ * platform-neutral handlers are defined in <linux/sys_hotplug.h>.
+ */
+
+/* Add Validate order values */
+#define SHP_ACPI_BUS_ADD_VALIDATE_ORDER 0 /* must be first */
+
+/* Add Execute order values */
+#define SHP_ACPI_BUS_ADD_EXECUTE_ORDER 10
+#define SHP_ACPI_RES_ADD_EXECUTE_ORDER 20
+
+/* Add Commit order values */
+#define SHP_ACPI_BUS_ADD_COMMIT_ORDER 10
+
+/* Delete Validate order values */
+#define SHP_ACPI_BUS_DEL_VALIDATE_ORDER 0 /* must be first */
+#define SHP_ACPI_RES_DEL_VALIDATE_ORDER 10
+
+/* Delete Execute order values */
+#define SHP_ACPI_BUS_DEL_EXECUTE_ORDER 100
+
+/* Delete Commit order values */
+#define SHP_ACPI_BUS_DEL_COMMIT_ORDER 100
+
+#endif /* _ACPI_SYS_HOTPLUG_H */
^ permalink raw reply related
* [RFC PATCH v2 10/12] ACPI: Update container driver for hotplug framework
From: Toshi Kani @ 2013-01-10 23:40 UTC (permalink / raw)
To: rjw, lenb, gregkh, akpm
Cc: linux-s390, Toshi Kani, jiang.liu, wency, linux-mm, yinghai,
linux-kernel, linux-acpi, isimatu.yasuaki, srivatsa.bhat,
guohanjun, bhelgaas, linuxppc-dev
In-Reply-To: <1357861230-29549-1-git-send-email-toshi.kani@hp.com>
Changed container_notify_cb() to request a hotplug operation by
calling shp_submit_req(). It no longer initiates hot-add by calling
acpi_bus_add(). Also, it no longer sets device->flags.eject_pending
and generates KOBJ_OFFLINE event for hot-delete.
Signed-off-by: Toshi Kani <toshi.kani@hp.com>
---
drivers/acpi/container.c | 95 ++++++++++++++++++----------------------------
1 file changed, 37 insertions(+), 58 deletions(-)
diff --git a/drivers/acpi/container.c b/drivers/acpi/container.c
index 811910b..89af4fc 100644
--- a/drivers/acpi/container.c
+++ b/drivers/acpi/container.c
@@ -35,6 +35,7 @@
#include <acpi/acpi_bus.h>
#include <acpi/acpi_drivers.h>
#include <acpi/container.h>
+#include <acpi/sys_hotplug.h>
#define PREFIX "ACPI: "
@@ -135,77 +136,37 @@ static int acpi_container_remove(struct acpi_device *device, int type)
return status;
}
-static int container_device_add(struct acpi_device **device, acpi_handle handle)
-{
- acpi_handle phandle;
- struct acpi_device *pdev;
- int result;
-
-
- if (acpi_get_parent(handle, &phandle)) {
- return -ENODEV;
- }
-
- if (acpi_bus_get_device(phandle, &pdev)) {
- return -ENODEV;
- }
-
- if (acpi_bus_add(device, pdev, handle, ACPI_BUS_TYPE_DEVICE)) {
- return -ENODEV;
- }
-
- result = acpi_bus_start(*device);
-
- return result;
-}
-
-static void container_notify_cb(acpi_handle handle, u32 type, void *context)
+static void container_notify_cb(acpi_handle handle, u32 event, void *context)
{
struct acpi_device *device = NULL;
- int result;
- int present;
- acpi_status status;
+ struct shp_request *shp_req;
+ enum shp_operation shp_op;
u32 ost_code = ACPI_OST_SC_NON_SPECIFIC_FAILURE; /* default */
- switch (type) {
+ switch (event) {
case ACPI_NOTIFY_BUS_CHECK:
/* Fall through */
case ACPI_NOTIFY_DEVICE_CHECK:
- pr_debug("Container driver received %s event\n",
- (type == ACPI_NOTIFY_BUS_CHECK) ?
- "ACPI_NOTIFY_BUS_CHECK" : "ACPI_NOTIFY_DEVICE_CHECK");
-
- present = is_device_present(handle);
- status = acpi_bus_get_device(handle, &device);
- if (!present) {
- if (ACPI_SUCCESS(status)) {
- /* device exist and this is a remove request */
- device->flags.eject_pending = 1;
- kobject_uevent(&device->dev.kobj, KOBJ_OFFLINE);
- return;
- }
- break;
+ if (!is_device_present(handle)) {
+ acpi_handle_err(handle, "Device not enabled\n");
+ goto err;
}
- if (!ACPI_FAILURE(status) || device)
- break;
-
- result = container_device_add(&device, handle);
- if (result) {
- acpi_handle_warn(handle, "Failed to add container\n");
- break;
+ if (!acpi_bus_get_device(handle, &device)) {
+ acpi_handle_err(handle, "Device added already\n");
+ goto err;
}
- kobject_uevent(&device->dev.kobj, KOBJ_ONLINE);
- ost_code = ACPI_OST_SC_SUCCESS;
+ shp_op = SHP_HOTPLUG_ADD;
break;
case ACPI_NOTIFY_EJECT_REQUEST:
- if (!acpi_bus_get_device(handle, &device) && device) {
- device->flags.eject_pending = 1;
- kobject_uevent(&device->dev.kobj, KOBJ_OFFLINE);
- return;
+ if (acpi_bus_get_device(handle, &device)) {
+ acpi_handle_err(handle, "Device not added yet\n");
+ goto err;
}
+
+ shp_op = SHP_HOTPLUG_DEL;
break;
default:
@@ -213,8 +174,26 @@ static void container_notify_cb(acpi_handle handle, u32 type, void *context)
return;
}
- /* Inform firmware that the hotplug operation has completed */
- (void) acpi_evaluate_hotplug_ost(handle, type, ost_code, NULL);
+ shp_req = shp_alloc_request(shp_op);
+ if (!shp_req) {
+ acpi_handle_err(handle, "No memory to request hotplug\n");
+ goto err;
+ }
+
+ shp_req->handle = (void *)handle;
+ shp_req->event = event;
+
+ if (shp_submit_req(shp_req)) {
+ acpi_handle_err(handle, "Failed to request hotplug\n");
+ kfree(shp_req);
+ goto err;
+ }
+
+ return;
+
+err:
+ /* Inform firmware that the hotplug operation completed w/ error */
+ (void) acpi_evaluate_hotplug_ost(handle, event, ost_code, NULL);
return;
}
^ permalink raw reply related
* [RFC PATCH v2 12/12] ACPI: Update sysfs eject for hotplug framework
From: Toshi Kani @ 2013-01-10 23:40 UTC (permalink / raw)
To: rjw, lenb, gregkh, akpm
Cc: linux-s390, Toshi Kani, jiang.liu, wency, linux-mm, yinghai,
linux-kernel, linux-acpi, isimatu.yasuaki, srivatsa.bhat,
guohanjun, bhelgaas, linuxppc-dev
In-Reply-To: <1357861230-29549-1-git-send-email-toshi.kani@hp.com>
Changed acpi_eject_store() to request a hot-delete operation by
calling shp_submit_req(). It no longer initiates a hot-delete
operation by calling acpi_bus_hot_remove_device().
Deleted acpi_bus_hot_remove_device() since it no longer has any
caller and should not be called for hot-delete.
Deleted eject_pending bit from acpi_device_flags since the ACPI
container driver no longer sets it for hot-delete, and sysfs
eject no longer checks it in acpi_bus_hot_remove_device().
Signed-off-by: Toshi Kani <toshi.kani@hp.com>
---
drivers/acpi/scan.c | 122 ++++++++---------------------------------------
include/acpi/acpi_bus.h | 4 --
2 files changed, 23 insertions(+), 103 deletions(-)
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index c88be6c..5e47b49 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -13,6 +13,7 @@
#include <linux/nls.h>
#include <acpi/acpi_drivers.h>
+#include <acpi/sys_hotplug.h>
#include "internal.h"
@@ -105,85 +106,6 @@ acpi_device_modalias_show(struct device *dev, struct device_attribute *attr, cha
}
static DEVICE_ATTR(modalias, 0444, acpi_device_modalias_show, NULL);
-/**
- * acpi_bus_hot_remove_device: hot-remove a device and its children
- * @context: struct acpi_eject_event pointer (freed in this func)
- *
- * Hot-remove a device and its children. This function frees up the
- * memory space passed by arg context, so that the caller may call
- * this function asynchronously through acpi_os_hotplug_execute().
- */
-void acpi_bus_hot_remove_device(void *context)
-{
- struct acpi_eject_event *ej_event = (struct acpi_eject_event *) context;
- struct acpi_device *device;
- acpi_handle handle = ej_event->handle;
- acpi_handle temp;
- struct acpi_object_list arg_list;
- union acpi_object arg;
- acpi_status status = AE_OK;
- u32 ost_code = ACPI_OST_SC_NON_SPECIFIC_FAILURE; /* default */
-
- if (acpi_bus_get_device(handle, &device))
- goto err_out;
-
- if (!device)
- goto err_out;
-
- ACPI_DEBUG_PRINT((ACPI_DB_INFO,
- "Hot-removing device %s...\n", dev_name(&device->dev)));
-
- if (acpi_bus_trim(device, 1)) {
- printk(KERN_ERR PREFIX
- "Removing device failed\n");
- goto err_out;
- }
-
- /* device has been freed */
- device = NULL;
-
- /* power off device */
- status = acpi_evaluate_object(handle, "_PS3", NULL, NULL);
- if (ACPI_FAILURE(status) && status != AE_NOT_FOUND)
- printk(KERN_WARNING PREFIX
- "Power-off device failed\n");
-
- if (ACPI_SUCCESS(acpi_get_handle(handle, "_LCK", &temp))) {
- arg_list.count = 1;
- arg_list.pointer = &arg;
- arg.type = ACPI_TYPE_INTEGER;
- arg.integer.value = 0;
- acpi_evaluate_object(handle, "_LCK", &arg_list, NULL);
- }
-
- arg_list.count = 1;
- arg_list.pointer = &arg;
- arg.type = ACPI_TYPE_INTEGER;
- arg.integer.value = 1;
-
- /*
- * TBD: _EJD support.
- */
- status = acpi_evaluate_object(handle, "_EJ0", &arg_list, NULL);
- if (ACPI_FAILURE(status)) {
- if (status != AE_NOT_FOUND)
- printk(KERN_WARNING PREFIX
- "Eject device failed\n");
- goto err_out;
- }
-
- kfree(context);
- return;
-
-err_out:
- /* Inform firmware the hot-remove operation has completed w/ error */
- (void) acpi_evaluate_hotplug_ost(handle,
- ej_event->event, ost_code, NULL);
- kfree(context);
- return;
-}
-EXPORT_SYMBOL(acpi_bus_hot_remove_device);
-
static ssize_t
acpi_eject_store(struct device *d, struct device_attribute *attr,
const char *buf, size_t count)
@@ -192,44 +114,44 @@ acpi_eject_store(struct device *d, struct device_attribute *attr,
acpi_status status;
acpi_object_type type = 0;
struct acpi_device *acpi_device = to_acpi_device(d);
- struct acpi_eject_event *ej_event;
+ struct shp_request *shp_req;
if ((!count) || (buf[0] != '1')) {
return -EINVAL;
}
#ifndef FORCE_EJECT
if (acpi_device->driver == NULL) {
- ret = -ENODEV;
- goto err;
+ return -ENODEV;
}
#endif
status = acpi_get_type(acpi_device->handle, &type);
if (ACPI_FAILURE(status) || (!acpi_device->flags.ejectable)) {
- ret = -ENODEV;
- goto err;
+ return -ENODEV;
}
- ej_event = kmalloc(sizeof(*ej_event), GFP_KERNEL);
- if (!ej_event) {
- ret = -ENOMEM;
+ shp_req = shp_alloc_request(SHP_HOTPLUG_DEL);
+ if (!shp_req)
+ return -ENOMEM;
+
+ shp_req->handle = (void *) acpi_device->handle;
+
+ /* event originated from user */
+ shp_req->event = ACPI_OST_EC_OSPM_EJECT;
+ (void) acpi_evaluate_hotplug_ost(shp_req->handle,
+ shp_req->event, ACPI_OST_SC_EJECT_IN_PROGRESS, NULL);
+
+ if (shp_submit_req(shp_req)) {
+ kfree(shp_req);
goto err;
}
- ej_event->handle = acpi_device->handle;
- if (acpi_device->flags.eject_pending) {
- /* event originated from ACPI eject notification */
- ej_event->event = ACPI_NOTIFY_EJECT_REQUEST;
- acpi_device->flags.eject_pending = 0;
- } else {
- /* event originated from user */
- ej_event->event = ACPI_OST_EC_OSPM_EJECT;
- (void) acpi_evaluate_hotplug_ost(ej_event->handle,
- ej_event->event, ACPI_OST_SC_EJECT_IN_PROGRESS, NULL);
- }
+ return ret;
- acpi_os_hotplug_execute(acpi_bus_hot_remove_device, (void *)ej_event);
err:
- return ret;
+ /* Inform firmware that the hotplug operation completed w/ error */
+ (void) acpi_evaluate_hotplug_ost(shp_req->handle,
+ shp_req->event, ACPI_OST_SC_NON_SPECIFIC_FAILURE, NULL);
+ return -EINVAL;
}
static DEVICE_ATTR(eject, 0200, NULL, acpi_eject_store);
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index 6bf002e..ccbfef3 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -151,8 +151,7 @@ struct acpi_device_flags {
u32 suprise_removal_ok:1;
u32 power_manageable:1;
u32 performance_manageable:1;
- u32 eject_pending:1;
- u32 reserved:24;
+ u32 reserved:25;
};
/* File System */
@@ -362,7 +361,6 @@ int acpi_bus_register_driver(struct acpi_driver *driver);
void acpi_bus_unregister_driver(struct acpi_driver *driver);
int acpi_bus_add(struct acpi_device **child, struct acpi_device *parent,
acpi_handle handle, int type);
-void acpi_bus_hot_remove_device(void *context);
int acpi_bus_trim(struct acpi_device *start, int rmdevice);
int acpi_bus_start(struct acpi_device *device);
acpi_status acpi_bus_get_ejd(acpi_handle handle, acpi_handle * ejd);
^ permalink raw reply related
* [RFC PATCH v2 09/12] ACPI: Update memory driver for hotplug framework
From: Toshi Kani @ 2013-01-10 23:40 UTC (permalink / raw)
To: rjw, lenb, gregkh, akpm
Cc: linux-s390, Toshi Kani, jiang.liu, wency, linux-mm, yinghai,
linux-kernel, linux-acpi, isimatu.yasuaki, srivatsa.bhat,
guohanjun, bhelgaas, linuxppc-dev
In-Reply-To: <1357861230-29549-1-git-send-email-toshi.kani@hp.com>
Changed acpi_memory_device_notify() to request a hotplug operation
by calling shp_submit_req(). It no longer initiates hot-add or
hot-delete operation by calling add_memory() or remove_memory()
directly. Removed the enabled and failed flags from acpi_memory_info
since they are no longer used.
Changed acpi_memory_device_add() to not call add_memory() to online
a memory device. Similarly, changed acpi_memory_device_remove()
to not call remove_memory() to offline a memory device.
Added acpi_memory_resource() to set memory information to a hotplug
request.
Signed-off-by: Toshi Kani <toshi.kani@hp.com>
---
drivers/acpi/acpi_memhotplug.c | 271 +++++++++++++---------------------------
1 file changed, 89 insertions(+), 182 deletions(-)
diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
index b679bf8..67868f5 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -33,6 +33,7 @@
#include <linux/slab.h>
#include <linux/acpi.h>
#include <acpi/acpi_drivers.h>
+#include <acpi/sys_hotplug.h>
#define ACPI_MEMORY_DEVICE_CLASS "memory"
#define ACPI_MEMORY_DEVICE_HID "PNP0C80"
@@ -55,6 +56,8 @@ MODULE_LICENSE("GPL");
static int acpi_memory_device_add(struct acpi_device *device);
static int acpi_memory_device_remove(struct acpi_device *device, int type);
+static int acpi_memory_device_resource(struct acpi_device *device,
+ struct shp_request *shp_req);
static const struct acpi_device_id memory_device_ids[] = {
{ACPI_MEMORY_DEVICE_HID, 0},
@@ -69,6 +72,7 @@ static struct acpi_driver acpi_memory_device_driver = {
.ops = {
.add = acpi_memory_device_add,
.remove = acpi_memory_device_remove,
+ .resource = acpi_memory_device_resource,
},
};
@@ -153,59 +157,12 @@ acpi_memory_get_device_resources(struct acpi_memory_device *mem_device)
return 0;
}
-static int
-acpi_memory_get_device(acpi_handle handle,
- struct acpi_memory_device **mem_device)
-{
- acpi_status status;
- acpi_handle phandle;
- struct acpi_device *device = NULL;
- struct acpi_device *pdevice = NULL;
- int result;
-
-
- if (!acpi_bus_get_device(handle, &device) && device)
- goto end;
-
- status = acpi_get_parent(handle, &phandle);
- if (ACPI_FAILURE(status)) {
- ACPI_EXCEPTION((AE_INFO, status, "Cannot find acpi parent"));
- return -EINVAL;
- }
-
- /* Get the parent device */
- result = acpi_bus_get_device(phandle, &pdevice);
- if (result) {
- acpi_handle_warn(phandle, "Cannot get acpi bus device\n");
- return -EINVAL;
- }
-
- /*
- * Now add the notified device. This creates the acpi_device
- * and invokes .add function
- */
- result = acpi_bus_add(&device, pdevice, handle, ACPI_BUS_TYPE_DEVICE);
- if (result) {
- acpi_handle_warn(handle, "Cannot add acpi bus\n");
- return -EINVAL;
- }
-
- end:
- *mem_device = acpi_driver_data(device);
- if (!(*mem_device)) {
- dev_err(&device->dev, "driver data not found\n");
- return -ENODEV;
- }
-
- return 0;
-}
-
-static int acpi_memory_check_device(struct acpi_memory_device *mem_device)
+static int acpi_memory_check_device(acpi_handle handle)
{
unsigned long long current_status;
/* Get device present/absent information from the _STA */
- if (ACPI_FAILURE(acpi_evaluate_integer(mem_device->device->handle, "_STA",
+ if (ACPI_FAILURE(acpi_evaluate_integer(handle, "_STA",
NULL, ¤t_status)))
return -ENODEV;
/*
@@ -220,148 +177,46 @@ static int acpi_memory_check_device(struct acpi_memory_device *mem_device)
return 0;
}
-static int acpi_memory_enable_device(struct acpi_memory_device *mem_device)
-{
- int result, num_enabled = 0;
- struct acpi_memory_info *info;
- int node;
-
- node = acpi_get_node(mem_device->device->handle);
- /*
- * Tell the VM there is more memory here...
- * Note: Assume that this function returns zero on success
- * We don't have memory-hot-add rollback function,now.
- * (i.e. memory-hot-remove function)
- */
- list_for_each_entry(info, &mem_device->res_list, list) {
- if (info->enabled) { /* just sanity check...*/
- num_enabled++;
- continue;
- }
- /*
- * If the memory block size is zero, please ignore it.
- * Don't try to do the following memory hotplug flowchart.
- */
- if (!info->length)
- continue;
- if (node < 0)
- node = memory_add_physaddr_to_nid(info->start_addr);
-
- result = add_memory(node, info->start_addr, info->length);
-
- /*
- * If the memory block has been used by the kernel, add_memory()
- * returns -EEXIST. If add_memory() returns the other error, it
- * means that this memory block is not used by the kernel.
- */
- if (result && result != -EEXIST) {
- info->failed = 1;
- continue;
- }
-
- if (!result)
- info->enabled = 1;
- /*
- * Add num_enable even if add_memory() returns -EEXIST, so the
- * device is bound to this driver.
- */
- num_enabled++;
- }
- if (!num_enabled) {
- dev_err(&mem_device->device->dev, "add_memory failed\n");
- mem_device->state = MEMORY_INVALID_STATE;
- return -EINVAL;
- }
- /*
- * Sometimes the memory device will contain several memory blocks.
- * When one memory block is hot-added to the system memory, it will
- * be regarded as a success.
- * Otherwise if the last memory block can't be hot-added to the system
- * memory, it will be failure and the memory device can't be bound with
- * driver.
- */
- return 0;
-}
-
-static int acpi_memory_remove_memory(struct acpi_memory_device *mem_device)
-{
- int result = 0;
- struct acpi_memory_info *info, *n;
-
- list_for_each_entry_safe(info, n, &mem_device->res_list, list) {
- if (info->failed)
- /* The kernel does not use this memory block */
- continue;
-
- if (!info->enabled)
- /*
- * The kernel uses this memory block, but it may be not
- * managed by us.
- */
- return -EBUSY;
-
- result = remove_memory(info->start_addr, info->length);
- if (result)
- return result;
-
- list_del(&info->list);
- kfree(info);
- }
-
- return result;
-}
-
static void acpi_memory_device_notify(acpi_handle handle, u32 event, void *data)
{
struct acpi_memory_device *mem_device;
struct acpi_device *device;
- struct acpi_eject_event *ej_event = NULL;
+ struct shp_request *shp_req;
+ enum shp_operation shp_op;
u32 ost_code = ACPI_OST_SC_NON_SPECIFIC_FAILURE; /* default */
switch (event) {
case ACPI_NOTIFY_BUS_CHECK:
- ACPI_DEBUG_PRINT((ACPI_DB_INFO,
- "\nReceived BUS CHECK notification for device\n"));
/* Fall Through */
case ACPI_NOTIFY_DEVICE_CHECK:
- if (event == ACPI_NOTIFY_DEVICE_CHECK)
- ACPI_DEBUG_PRINT((ACPI_DB_INFO,
- "\nReceived DEVICE CHECK notification for device\n"));
- if (acpi_memory_get_device(handle, &mem_device)) {
- acpi_handle_err(handle, "Cannot find driver data\n");
- break;
+ if (acpi_memory_check_device(handle)) {
+ acpi_handle_err(handle, "Device not enabled\n");
+ goto err;
+ }
+
+ if (!acpi_bus_get_device(handle, &device)) {
+ acpi_handle_err(handle, "Device added already\n");
+ goto err;
}
- ost_code = ACPI_OST_SC_SUCCESS;
+ shp_op = SHP_HOTPLUG_ADD;
break;
case ACPI_NOTIFY_EJECT_REQUEST:
- ACPI_DEBUG_PRINT((ACPI_DB_INFO,
- "\nReceived EJECT REQUEST notification for device\n"));
-
if (acpi_bus_get_device(handle, &device)) {
acpi_handle_err(handle, "Device doesn't exist\n");
- break;
+ goto err;
}
+
mem_device = acpi_driver_data(device);
if (!mem_device) {
acpi_handle_err(handle, "Driver Data is NULL\n");
- break;
+ goto err;
}
- ej_event = kmalloc(sizeof(*ej_event), GFP_KERNEL);
- if (!ej_event) {
- pr_err(PREFIX "No memory, dropping EJECT\n");
- break;
- }
-
- ej_event->handle = handle;
- ej_event->event = ACPI_NOTIFY_EJECT_REQUEST;
- acpi_os_hotplug_execute(acpi_bus_hot_remove_device,
- (void *)ej_event);
+ shp_op = SHP_HOTPLUG_DEL;
+ break;
- /* eject is performed asynchronously */
- return;
default:
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
"Unsupported event [0x%x]\n", event));
@@ -370,7 +225,25 @@ static void acpi_memory_device_notify(acpi_handle handle, u32 event, void *data)
return;
}
- /* Inform firmware that the hotplug operation has completed */
+ shp_req = shp_alloc_request(shp_op);
+ if (!shp_req) {
+ acpi_handle_err(handle, "No memory to request hotplug\n");
+ goto err;
+ }
+
+ shp_req->handle = (void *)handle;
+ shp_req->event = event;
+
+ if (shp_submit_req(shp_req)) {
+ acpi_handle_err(handle, "Failed to request hotplug\n");
+ kfree(shp_req);
+ goto err;
+ }
+
+ return;
+
+err:
+ /* Inform firmware that the hotplug operation completed w/ error */
(void) acpi_evaluate_hotplug_ost(handle, event, ost_code, NULL);
return;
}
@@ -414,38 +287,72 @@ static int acpi_memory_device_add(struct acpi_device *device)
mem_device->state = MEMORY_POWER_ON_STATE;
pr_debug("%s\n", acpi_device_name(device));
-
- if (!acpi_memory_check_device(mem_device)) {
- /* call add_memory func */
- result = acpi_memory_enable_device(mem_device);
- if (result) {
- dev_err(&device->dev,
- "Error in acpi_memory_enable_device\n");
- acpi_memory_device_free(mem_device);
- }
- }
return result;
}
static int acpi_memory_device_remove(struct acpi_device *device, int type)
{
struct acpi_memory_device *mem_device = NULL;
- int result;
+ struct acpi_memory_info *info, *n;
if (!device || !acpi_driver_data(device))
return -EINVAL;
mem_device = acpi_driver_data(device);
- result = acpi_memory_remove_memory(mem_device);
- if (result)
- return result;
+ /* remove the memory_info list of this mem_device */
+ list_for_each_entry_safe(info, n, &mem_device->res_list, list) {
+ list_del(&info->list);
+ kfree(info);
+ }
acpi_memory_device_free(mem_device);
return 0;
}
+static int acpi_memory_device_resource(struct acpi_device *device,
+ struct shp_request *shp_req)
+{
+ struct acpi_memory_device *mem_device = NULL;
+ struct acpi_memory_info *info, *n;
+ struct shp_device *shp_dev;
+ int node;
+
+ mem_device = acpi_driver_data(device);
+ if (!mem_device) {
+ dev_err(&device->dev, "Invalid device\n");
+ return -EINVAL;
+ }
+
+ node = acpi_get_node(mem_device->device->handle);
+
+ /*
+ * Set resource info of the device
+ */
+ list_for_each_entry_safe(info, n, &mem_device->res_list, list) {
+
+ if (!info->length)
+ continue;
+
+ shp_dev = kzalloc(sizeof(*shp_dev), GFP_KERNEL);
+ if (!shp_dev) {
+ dev_err(&device->dev, "Failed to allocate shp_dev\n");
+ return -EINVAL;
+ }
+
+ shp_dev->device = &device->dev;
+ shp_dev->class = SHP_CLS_MEMORY;
+ shp_dev->info.mem.node = node;
+ shp_dev->info.mem.start_addr = info->start_addr;
+ shp_dev->info.mem.length = info->length;
+
+ shp_add_dev_info(shp_req, shp_dev);
+ }
+
+ return 0;
+}
+
/*
* Helper function to check for memory device
*/
^ permalink raw reply related
* Re: [PATCH] PowerPC documentation: fixed path to the powerpc directory
From: Benjamin Herrenschmidt @ 2013-01-10 23:00 UTC (permalink / raw)
To: Thomas Waldecker; +Cc: linuxppc-dev, paulus, linux-kernel, rob, linux-doc
In-Reply-To: <1357819632-30814-1-git-send-email-thomas.waldecker@gmail.com>
On Thu, 2013-01-10 at 13:07 +0100, Thomas Waldecker wrote:
> ppc -> powerpc
I think I already applied something like that in powerpc -next, can you
dbl check ?
Cheers,
Ben.
> Signed-off-by: Thomas Waldecker <thomas.waldecker@gmail.com>
> ---
> Documentation/powerpc/cpu_features.txt | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/powerpc/cpu_features.txt b/Documentation/powerpc/cpu_features.txt
> index ffa4183..ae09df8 100644
> --- a/Documentation/powerpc/cpu_features.txt
> +++ b/Documentation/powerpc/cpu_features.txt
> @@ -11,10 +11,10 @@ split instruction and data caches, and if the CPU supports the DOZE and NAP
> sleep modes.
>
> Detection of the feature set is simple. A list of processors can be found in
> -arch/ppc/kernel/cputable.c. The PVR register is masked and compared with each
> -value in the list. If a match is found, the cpu_features of cur_cpu_spec is
> -assigned to the feature bitmask for this processor and a __setup_cpu function
> -is called.
> +arch/powerpc/kernel/cputable.c. The PVR register is masked and compared with
> +each value in the list. If a match is found, the cpu_features of cur_cpu_spec
> +is assigned to the feature bitmask for this processor and a __setup_cpu
> +function is called.
>
> C code may test 'cur_cpu_spec[smp_processor_id()]->cpu_features' for a
> particular feature bit. This is done in quite a few places, for example
> @@ -51,6 +51,6 @@ should be used in the majority of cases.
>
> The END_FTR_SECTION macros are implemented by storing information about this
> code in the '__ftr_fixup' ELF section. When do_cpu_ftr_fixups
> -(arch/ppc/kernel/misc.S) is invoked, it will iterate over the records in
> +(arch/powerpc/kernel/misc.S) is invoked, it will iterate over the records in
> __ftr_fixup, and if the required feature is not present it will loop writing
> nop's from each BEGIN_FTR_SECTION to END_FTR_SECTION.
^ permalink raw reply
* Re: [PATCH] Added device tree binding for TDM and TDM phy
From: Scott Wood @ 2013-01-10 19:48 UTC (permalink / raw)
To: Singh Sandeep-B37400
Cc: Wood Scott-B07421, devicetree-discuss@lists.ozlabs.org,
Aggrwal Poonam-B10812, linuxppc-dev@ozlabs.org
In-Reply-To: <3F1D9DCAAB49B94D88DBE05911FA4E6E69E4F0@039-SN1MPN1-005.039d.mgd.msft.net>
On 01/10/2013 03:24:21 AM, Singh Sandeep-B37400 wrote:
> > > > +- compatible
> > > > + Value type: <string>
> > > > + Definition: Should contain generic compatibility like
> > > "tdm-phy-slic"
> > > > or
> > > > + "tdm-phy-e1" or "tdm-phy-t1".
> >
> > Does this "generic" string (plus the other properties) tell you all =20
> you
> > need to know about the device? If there are other possible =20
> "generic"
> > compatibles, they should be listed or else different people will =20
> make up
> > different strings for the same thing.
>=20
> This property will describe the type of device, and will help TDM =20
> framework
> to know if it is E1/T1/SLIC device. Further details can be extracted =20
> from other
> compatible strings.
> There are only three generic compatibles field types, which are =20
> already mentioned
> in definition. Do I need to make this thing more clear.
The word "like" suggests that there are other possibilites. It would =20
be clearer as:
Definition: One of "tdm-phy-slic", "tdm-phy-e1", or "tdm-phy-t1".
-Scott=
^ permalink raw reply
* [PATCH v2] ppc/iommu: use find_first_bit to look up entries in the iommu table
From: Thadeu Lima de Souza Cascardo @ 2013-01-10 19:33 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus, shangw, Thadeu Lima de Souza Cascardo, anton
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
---
v2:
Remove the unneeded extra variable i, which caused build failure.
---
arch/powerpc/kernel/iommu.c | 9 ++-------
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index 6d48ff8..0fc44d2 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -708,7 +708,7 @@ struct iommu_table *iommu_init_table(struct iommu_table *tbl, int nid)
void iommu_free_table(struct iommu_table *tbl, const char *node_name)
{
- unsigned long bitmap_sz, i;
+ unsigned long bitmap_sz;
unsigned int order;
if (!tbl || !tbl->it_map) {
@@ -725,14 +725,9 @@ void iommu_free_table(struct iommu_table *tbl, const char *node_name)
clear_bit(0, tbl->it_map);
/* verify that table contains no entries */
- /* it_size is in entries, and we're examining 64 at a time */
- for (i = 0; i < (tbl->it_size/64); i++) {
- if (tbl->it_map[i] != 0) {
+ if (find_first_bit(tbl->it_map, tbl->it_size) < tbl->it_size)
printk(KERN_WARNING "%s: Unexpected TCEs for %s\n",
__func__, node_name);
- break;
- }
- }
/* calculate bitmap size in bytes */
bitmap_sz = (tbl->it_size + 7) / 8;
--
1.7.1
^ permalink raw reply related
* Re: [TRIVIAL PATCH 11/26] powerpc: Convert print_symbol to %pSR
From: Joe Perches @ 2013-01-10 17:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: cbe-oss-dev, Jiri Kosina, Arnd Bergmann, linux-kernel,
Paul Mackerras, linuxppc-dev
In-Reply-To: <1357796898.4838.85.camel@pasglop>
On Thu, 2013-01-10 at 16:48 +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2012-12-13 at 11:58 +0000, Arnd Bergmann wrote:
> > On Wednesday 12 December 2012, Joe Perches wrote:
> > > Use the new vsprintf extension to avoid any possible
> > > message interleaving.
> > >
> > > Convert the #ifdef DEBUG block to a single pr_debug.
> > >
> > > Signed-off-by: Joe Perches <joe@perches.com>
> >
> > nice cleanup!
>
> ... which also breaks the build :-(
>
> > Acked-by: Arnd Bergmann <arnd@arndb.de>
>
> I'll fix it up locally.
OK, I didn't compile it.
How does it break the build?
^ permalink raw reply
* Re: [BUILD BREAK] usb: gadget: fsl_mxc_udc can't compile on current v3.8-rc3
From: Greg KH @ 2013-01-10 14:30 UTC (permalink / raw)
To: Felipe Balbi; +Cc: linuxppc-dev, linux-usb
In-Reply-To: <20130110100835.GB28920@arwen.pp.htv.fi>
On Thu, Jan 10, 2013 at 12:08:35PM +0200, Felipe Balbi wrote:
> Hi,
>
> Some recent patch has caused fsl_mxc_udc.c driver to fail compilation
> because it can't find <mach/hardware.h> anymore.
>
> I would like this to be fixed still during this -rc cycle.
Me too, who's sending a patch? :)
^ permalink raw reply
* [PATCH] PowerPC documentation: fixed path to the powerpc directory
From: Thomas Waldecker @ 2013-01-10 12:07 UTC (permalink / raw)
To: benh; +Cc: linux-doc, Thomas Waldecker, linux-kernel, paulus, rob,
linuxppc-dev
ppc -> powerpc
Signed-off-by: Thomas Waldecker <thomas.waldecker@gmail.com>
---
Documentation/powerpc/cpu_features.txt | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/powerpc/cpu_features.txt b/Documentation/powerpc/cpu_features.txt
index ffa4183..ae09df8 100644
--- a/Documentation/powerpc/cpu_features.txt
+++ b/Documentation/powerpc/cpu_features.txt
@@ -11,10 +11,10 @@ split instruction and data caches, and if the CPU supports the DOZE and NAP
sleep modes.
Detection of the feature set is simple. A list of processors can be found in
-arch/ppc/kernel/cputable.c. The PVR register is masked and compared with each
-value in the list. If a match is found, the cpu_features of cur_cpu_spec is
-assigned to the feature bitmask for this processor and a __setup_cpu function
-is called.
+arch/powerpc/kernel/cputable.c. The PVR register is masked and compared with
+each value in the list. If a match is found, the cpu_features of cur_cpu_spec
+is assigned to the feature bitmask for this processor and a __setup_cpu
+function is called.
C code may test 'cur_cpu_spec[smp_processor_id()]->cpu_features' for a
particular feature bit. This is done in quite a few places, for example
@@ -51,6 +51,6 @@ should be used in the majority of cases.
The END_FTR_SECTION macros are implemented by storing information about this
code in the '__ftr_fixup' ELF section. When do_cpu_ftr_fixups
-(arch/ppc/kernel/misc.S) is invoked, it will iterate over the records in
+(arch/powerpc/kernel/misc.S) is invoked, it will iterate over the records in
__ftr_fixup, and if the required feature is not present it will loop writing
nop's from each BEGIN_FTR_SECTION to END_FTR_SECTION.
--
1.8.0.2
^ permalink raw reply related
* [powerpc:next 54/54] arch/powerpc/kernel/exceptions-64s.S:1204: Error: attempt to move .org backwards
From: Fengguang Wu @ 2013-01-10 10:55 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <50ee8554.VPKmpSyDNCfRKVZL%yuanhan.liu@linux.intel.com>
Hi Benjamin,
FYI, kernel build failed on
tree: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git next
head: 61383407677aef05928541a00678591abea2d84c
config: make ARCH=powerpc allmodconfig
All error/warnings:
WARNING: arch/powerpc/mm/built-in.o(.cpuinit.text+0x292): Section mismatch in reference from the function .fake_numa_create_new_node() to the variable .init.data:cmdline
The function __cpuinit .fake_numa_create_new_node() references
a variable __initdata cmdline.
If cmdline is only used by .fake_numa_create_new_node then
annotate cmdline with a matching annotation.
--
arch/powerpc/kernel/kgdb.c: In function 'kgdb_arch_exit':
arch/powerpc/kernel/kgdb.c:492:2: error: '__debugger_breakx_match' undeclared (first use in this function)
arch/powerpc/kernel/kgdb.c:492:2: note: each undeclared identifier is reported only once for each function it appears in
--
arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
arch/powerpc/kernel/exceptions-64s.S:1204: Error: attempt to move .org backwards
--
drivers/tty/synclink_gt.c:160:12: error: conflicting types for 'set_break'
arch/powerpc/include/asm/debug.h:49:5: note: previous declaration of 'set_break' was here
--
drivers/tty/synclinkmp.c:526:12: error: conflicting types for 'set_break'
arch/powerpc/include/asm/debug.h:49:5: note: previous declaration of 'set_break' was here
vim +1204 arch/powerpc/kernel/exceptions-64s.S
61383407 Benjamin Herrenschmidt 2013-01-10 1198
61383407 Benjamin Herrenschmidt 2013-01-10 1199 #if defined(CONFIG_PPC_PSERIES) || defined(CONFIG_PPC_POWERNV)
61383407 Benjamin Herrenschmidt 2013-01-10 1200 /*
61383407 Benjamin Herrenschmidt 2013-01-10 1201 * Data area reserved for FWNMI option.
61383407 Benjamin Herrenschmidt 2013-01-10 1202 * This address (0x7000) is fixed by the RPA.
61383407 Benjamin Herrenschmidt 2013-01-10 1203 */
61383407 Benjamin Herrenschmidt 2013-01-10 @1204 .= 0x7000
61383407 Benjamin Herrenschmidt 2013-01-10 1205 .globl fwnmi_data_area
61383407 Benjamin Herrenschmidt 2013-01-10 1206 fwnmi_data_area:
61383407 Benjamin Herrenschmidt 2013-01-10 1207
---
0-DAY kernel build testing backend Open Source Technology Center
Fengguang Wu, Yuanhan Liu Intel Corporation
^ permalink raw reply
* [BUILD BREAK] usb: gadget: fsl_mxc_udc can't compile on current v3.8-rc3
From: Felipe Balbi @ 2013-01-10 10:08 UTC (permalink / raw)
To: leoli, gregkh, linux-usb, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 217 bytes --]
Hi,
Some recent patch has caused fsl_mxc_udc.c driver to fail compilation
because it can't find <mach/hardware.h> anymore.
I would like this to be fixed still during this -rc cycle.
Thank you
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* RE: [PATCH] Added device tree binding for TDM and TDM phy
From: Singh Sandeep-B37400 @ 2013-01-10 9:24 UTC (permalink / raw)
To: Wood Scott-B07421
Cc: linuxppc-dev@ozlabs.org, devicetree-discuss@lists.ozlabs.org,
Aggrwal Poonam-B10812
In-Reply-To: <1357776425.18196.18@snotra>
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Thursday, January 10, 2013 5:37 AM
> To: Singh Sandeep-B37400
> Cc: devicetree-discuss@lists.ozlabs.org; linuxppc-dev@ozlabs.org; Aggrwal
> Poonam-B10812
> Subject: Re: [PATCH] Added device tree binding for TDM and TDM phy
>=20
> On 01/09/2013 01:10:24 AM, Singh Sandeep-B37400 wrote:
> > A gentle reminder.
> > Any comments are appreciated.
> >
> > Regards,
> > Sandeep
> >
> > > -----Original Message-----
> > > From: Singh Sandeep-B37400
> > > Sent: Wednesday, January 02, 2013 6:55 PM
> > > To: devicetree-discuss@lists.ozlabs.org; linuxppc-dev@ozlabs.org
> > > Cc: Singh Sandeep-B37400; Aggrwal Poonam-B10812
> > > Subject: [PATCH] Added device tree binding for TDM and TDM phy
> > >
> > > This controller is available on many Freescale SOCs like MPC8315,
> > P1020,
> > > P1010 and P1022
> > >
> > > Signed-off-by: Sandeep Singh <Sandeep@freescale.com>
> > > Signed-off-by: Poonam Aggrwal <poonam.aggrwal@freescale.com>
> > > ---
> > > .../devicetree/bindings/powerpc/fsl/fsl-tdm.txt | 63
> > > ++++++++++++++++++++
> > > .../devicetree/bindings/powerpc/fsl/tdm-phy.txt | 38
> > ++++++++++++
> > > 2 files changed, 101 insertions(+), 0 deletions(-) create mode
> > 100644
> > > Documentation/devicetree/bindings/powerpc/fsl/fsl-tdm.txt
> > > create mode 100644
> > Documentation/devicetree/bindings/powerpc/fsl/tdm-
> > > phy.txt
> > >
> > > diff --git
> > a/Documentation/devicetree/bindings/powerpc/fsl/fsl-tdm.txt
> > > b/Documentation/devicetree/bindings/powerpc/fsl/fsl-tdm.txt
> > > new file mode 100644
> > > index 0000000..ceb2ef1
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/powerpc/fsl/fsl-tdm.txt
> > > @@ -0,0 +1,63 @@
> > > +TDM Device Tree Binding
> > > +
> > > +NOTE: The bindings described in this document are preliminary and
> > > +subject to change.
> > > +
> > > +TDM (Time Division Multiplexing)
> > > +
> > > +Description:
> > > +
> > > +The TDM is full duplex serial port designed to allow various
> > devices
> > > +including digital signal processors (DSPs) to communicate with a
> > > +variety of serial devices including industry standard framers,
> > codecs,
> > > other DSPs and microprocessors.
> > > +
> > > +The below properties describe the device tree bindings for
> > Freescale
> > > +TDM controller. This TDM controller is available on various
> > Freescale
> > > +Processors like MPC8315, P1020, P1022 and P1010.
> > > +
> > > +Required properties:
> > > +
> > > +- compatible
> > > + Value type: <string>
> > > + Definition: Should contain "fsl,tdm1.0".
> > > +
> > > +- reg
> > > + Definition: A standard property. The first reg specifier
> > describes
> > > the TDM
> > > + registers, and the second describes the TDM DMAC registers.
> > > +
> > > +- tdm_tx_clk
> > > + Value type: <u32 or u64>
> > > + Definition: This specifies the value of transmit clock. It
> > should
> > > not
> > > + exceed 50Mhz.
> > > +
> > > +- tdm_rx_clk
> > > + Value type: <u32 or u64>
> > > + Definition: This specifies the value of receive clock. Its
> > value
> > > could be
> > > + zero, in which case tdm will operate in shared mode. Its value
> > > should not
> > > + exceed 50Mhz.
>=20
> Please don't use underscores in property names, and use the vendor
> prefix: "fsl,tdm-tx-clk" and "fsl,tdm-rx-clk".
Ok.
>=20
> > > diff --git
> > a/Documentation/devicetree/bindings/powerpc/fsl/tdm-phy.txt
> > > b/Documentation/devicetree/bindings/powerpc/fsl/tdm-phy.txt
> > > new file mode 100644
> > > index 0000000..2563934
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/powerpc/fsl/tdm-phy.txt
> > > @@ -0,0 +1,38 @@
> > > +TDM PHY Device Tree Binding
> > > +
> > > +NOTE: The bindings described in this document are preliminary and
> > > +subject to change.
> > > +
> > > +Description:
> > > +TDM PHY is the terminal interface of TDM subsystem. It is
> > typically a
> > > +line control device like E1/T1 framer or SLIC. A TDM device can
> > have
> > > +multiple TDM PHYs.
> > > +
> > > +Required properties:
> > > +
> > > +- compatible
> > > + Value type: <string>
> > > + Definition: Should contain generic compatibility like
> > "tdm-phy-slic"
> > > or
> > > + "tdm-phy-e1" or "tdm-phy-t1".
>=20
> Does this "generic" string (plus the other properties) tell you all you
> need to know about the device? If there are other possible "generic"
> compatibles, they should be listed or else different people will make up
> different strings for the same thing.
This property will describe the type of device, and will help TDM framework
to know if it is E1/T1/SLIC device. Further details can be extracted from o=
ther
compatible strings.
There are only three generic compatibles field types, which are already men=
tioned
in definition. Do I need to make this thing more clear.
>=20
> -Scott
^ permalink raw reply
* [PATCH powerpc ] Avoid debug_smp_processor_id() check in arch_spin_unlock_wait()
From: Li Zhong @ 2013-01-10 9:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Paul Mackerras, Paul E. McKenney, PowerPC email list
In-Reply-To: <1357797726.4838.89.camel@pasglop>
Use local_paca directly in arch_spin_unlock_wait(), as all processors have the
same value for the field shared_proc, so we don't need care racy here.
Reported-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
---
arch/powerpc/lib/locks.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/lib/locks.c b/arch/powerpc/lib/locks.c
index bb7cfec..850bea6 100644
--- a/arch/powerpc/lib/locks.c
+++ b/arch/powerpc/lib/locks.c
@@ -72,7 +72,7 @@ void arch_spin_unlock_wait(arch_spinlock_t *lock)
{
while (lock->slock) {
HMT_low();
- if (SHARED_PROCESSOR)
+ if (local_paca->lppaca_ptr->shared_proc)
__spin_yield(lock);
}
HMT_medium();
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v6 00/15] memory-hotplug: hot-remove physical memory
From: Kamezawa Hiroyuki @ 2013-01-10 8:39 UTC (permalink / raw)
To: Glauber Costa
Cc: linux-ia64, linux-sh, Tang Chen, linux-mm, paulus, hpa,
sparclinux, cl, linux-s390, x86, linux-acpi, isimatu.yasuaki,
linfeng, mgorman, kosaki.motohiro, rientjes, len.brown, wency,
cmetcalf, wujianguo, yinghai, laijs, linux-kernel, minchan.kim,
Andrew Morton, linuxppc-dev
In-Reply-To: <50EE7D75.8080100@parallels.com>
(2013/01/10 17:36), Glauber Costa wrote:
>> BTW, shrink_slab() is now node/zone aware ? If not, fixing that first will
>> be better direction I guess.
>>
> It is not upstream, but there are patches for this that I am already
> using in my private tree.
>
Oh, I see. If it's merged, it's worth add "shrink_slab() if ZONE_NORMAL"
code.
Thanks,
-Kame
^ permalink raw reply
* Re: [PATCH v6 00/15] memory-hotplug: hot-remove physical memory
From: Glauber Costa @ 2013-01-10 8:36 UTC (permalink / raw)
To: Kamezawa Hiroyuki
Cc: linux-ia64, linux-sh, Tang Chen, linux-mm, paulus, hpa,
sparclinux, cl, linux-s390, x86, linux-acpi, isimatu.yasuaki,
linfeng, mgorman, kosaki.motohiro, rientjes, len.brown, wency,
cmetcalf, wujianguo, yinghai, laijs, linux-kernel, minchan.kim,
Andrew Morton, linuxppc-dev
In-Reply-To: <50EE7A6B.7020005@jp.fujitsu.com>
> If it's configure as ZONE_NORMAL, you need to pray for offlining memory.
>
> AFAIK, IBM's ppc? has 16MB section size. So, some of sections can be
> offlined
> even if they are configured as ZONE_NORMAL. For them, placement of offlined
> memory is not important because it's virtualized by LPAR, they don't try
> to remove DIMM, they just want to increase/decrease amount of memory.
> It's an another approach.
>
> But here, we(fujitsu) tries to remove a system board/DIMM.
> So, configuring the whole memory of a node as ZONE_MOVABLE and tries to
> guarantee
> DIMM as removable.
>
>>> IMHO, I don't think shrink_slab() can kill all objects in a node even
>>> if they are some caches. We need more study for doing that.
>>>
>>
>> Indeed, shrink_slab can only kill cached objects. They, however, are
>> usually a very big part of kernel memory. I wonder though if in case of
>> failure, it is worth it to try at least one shrink pass before you
>> give up.
>>
>
> Yeah, now, his (our) approach is never allowing kernel memory on a node
> to be
> hot-removed by ZONE_MOVABLE. So, shrink_slab()'s effect will not be seen.
Ok, that clarifies it to me.
>
> If other brave guys tries to use ZONE_NORMAL for hot-pluggable DIMM, I see,
> it's worth triying.
>
I was under the impression that this was being done in here.
> How about checking the target memsection is in NORMAL or in MOVABLE at
> hot-removing ? If NORMAL, shrink_slab() will be worth to be called.
>
Yes, this is what I meant. I think there is value investigating this,
since for a lot of workloads, a lot of the kernel memory will consist of
shrinkable cached memory. It would provide you with the same level of
guarantees (zero), but can improve the success rate (this is, of
course, a guess)
> BTW, shrink_slab() is now node/zone aware ? If not, fixing that first will
> be better direction I guess.
>
It is not upstream, but there are patches for this that I am already
using in my private tree.
^ permalink raw reply
* Re: [PATCH v6 00/15] memory-hotplug: hot-remove physical memory
From: Kamezawa Hiroyuki @ 2013-01-10 8:23 UTC (permalink / raw)
To: Glauber Costa
Cc: linux-ia64, linux-sh, Tang Chen, linux-mm, paulus, hpa,
sparclinux, cl, linux-s390, x86, linux-acpi, isimatu.yasuaki,
linfeng, mgorman, kosaki.motohiro, rientjes, len.brown, wency,
cmetcalf, wujianguo, yinghai, laijs, linux-kernel, minchan.kim,
Andrew Morton, linuxppc-dev
In-Reply-To: <50EE73DE.30208@parallels.com>
(2013/01/10 16:55), Glauber Costa wrote:
> On 01/10/2013 11:31 AM, Kamezawa Hiroyuki wrote:
>> (2013/01/10 16:14), Glauber Costa wrote:
>>> On 01/10/2013 06:17 AM, Tang Chen wrote:
>>>>>> Note: if the memory provided by the memory device is used by the
>>>>>> kernel, it
>>>>>> can't be offlined. It is not a bug.
>>>>>
>>>>> Right. But how often does this happen in testing? In other words,
>>>>> please provide an overall description of how well memory hot-remove is
>>>>> presently operating. Is it reliable? What is the success rate in
>>>>> real-world situations?
>>>>
>>>> We test the hot-remove functionality mostly with movable_online used.
>>>> And the memory used by kernel is not allowed to be removed.
>>>
>>> Can you try doing this using cpusets configured to hardwall ?
>>> It is my understanding that the object allocators will try hard not to
>>> allocate anything outside the walls defined by cpuset. Which means that
>>> if you have one process per node, and they are hardwalled, your kernel
>>> memory will be spread evenly among the machine. With a big enough load,
>>> they should eventually be present in all blocks.
>>>
>>
>> I'm sorry I couldn't catch your point.
>> Do you want to confirm whether cpuset can work enough instead of
>> ZONE_MOVABLE ?
>> Or Do you want to confirm whether ZONE_MOVABLE will not work if it's
>> used with cpuset ?
>>
>>
> No, I am not proposing to use cpuset do tackle the problem. I am just
> wondering if you would still have high success rates with cpusets in use
> with hardwalls. This is just one example of a workload that would spread
> kernel memory around quite heavily.
>
> So this is just me trying to understand the limitations of the mechanism.
>
Hm, okay. In my undestanding, if the whole memory of a node is configured as
MOVABLE, no kernel memory will not be allocated in the node because zonelist
will not match. So, if cpuset is used with hardwalls, user will see -ENOMEM or OOM,
I guess. even fork() will fail if fallback-to-other-node is not allowed.
If it's configure as ZONE_NORMAL, you need to pray for offlining memory.
AFAIK, IBM's ppc? has 16MB section size. So, some of sections can be offlined
even if they are configured as ZONE_NORMAL. For them, placement of offlined
memory is not important because it's virtualized by LPAR, they don't try
to remove DIMM, they just want to increase/decrease amount of memory.
It's an another approach.
But here, we(fujitsu) tries to remove a system board/DIMM.
So, configuring the whole memory of a node as ZONE_MOVABLE and tries to guarantee
DIMM as removable.
>> IMHO, I don't think shrink_slab() can kill all objects in a node even
>> if they are some caches. We need more study for doing that.
>>
>
> Indeed, shrink_slab can only kill cached objects. They, however, are
> usually a very big part of kernel memory. I wonder though if in case of
> failure, it is worth it to try at least one shrink pass before you give up.
>
Yeah, now, his (our) approach is never allowing kernel memory on a node to be
hot-removed by ZONE_MOVABLE. So, shrink_slab()'s effect will not be seen.
If other brave guys tries to use ZONE_NORMAL for hot-pluggable DIMM, I see,
it's worth triying.
How about checking the target memsection is in NORMAL or in MOVABLE at
hot-removing ? If NORMAL, shrink_slab() will be worth to be called.
BTW, shrink_slab() is now node/zone aware ? If not, fixing that first will
be better direction I guess.
Thanks,
-Kame
^ permalink raw reply
* Re: [PATCH v6 00/15] memory-hotplug: hot-remove physical memory
From: Glauber Costa @ 2013-01-10 7:55 UTC (permalink / raw)
To: Kamezawa Hiroyuki
Cc: linux-ia64, linux-sh, Tang Chen, linux-mm, paulus, hpa,
sparclinux, cl, linux-s390, x86, linux-acpi, isimatu.yasuaki,
linfeng, mgorman, kosaki.motohiro, rientjes, len.brown, wency,
cmetcalf, wujianguo, yinghai, laijs, linux-kernel, minchan.kim,
Andrew Morton, linuxppc-dev
In-Reply-To: <50EE6E50.3040609@jp.fujitsu.com>
On 01/10/2013 11:31 AM, Kamezawa Hiroyuki wrote:
> (2013/01/10 16:14), Glauber Costa wrote:
>> On 01/10/2013 06:17 AM, Tang Chen wrote:
>>>>> Note: if the memory provided by the memory device is used by the
>>>>> kernel, it
>>>>> can't be offlined. It is not a bug.
>>>>
>>>> Right. But how often does this happen in testing? In other words,
>>>> please provide an overall description of how well memory hot-remove is
>>>> presently operating. Is it reliable? What is the success rate in
>>>> real-world situations?
>>>
>>> We test the hot-remove functionality mostly with movable_online used.
>>> And the memory used by kernel is not allowed to be removed.
>>
>> Can you try doing this using cpusets configured to hardwall ?
>> It is my understanding that the object allocators will try hard not to
>> allocate anything outside the walls defined by cpuset. Which means that
>> if you have one process per node, and they are hardwalled, your kernel
>> memory will be spread evenly among the machine. With a big enough load,
>> they should eventually be present in all blocks.
>>
>
> I'm sorry I couldn't catch your point.
> Do you want to confirm whether cpuset can work enough instead of
> ZONE_MOVABLE ?
> Or Do you want to confirm whether ZONE_MOVABLE will not work if it's
> used with cpuset ?
>
>
No, I am not proposing to use cpuset do tackle the problem. I am just
wondering if you would still have high success rates with cpusets in use
with hardwalls. This is just one example of a workload that would spread
kernel memory around quite heavily.
So this is just me trying to understand the limitations of the mechanism.
>> Another question I have for you: Have you considering calling
>> shrink_slab to try to deplete the caches and therefore free at least
>> slab memory in the nodes that can't be offlined? Is it relevant?
>>
>
> At this stage, we don't consider to call shrink_slab(). We require
> nearly 100% success at offlining memory for removing DIMM.
> It's my understanding.
>
Of course, this is indisputable.
> IMHO, I don't think shrink_slab() can kill all objects in a node even
> if they are some caches. We need more study for doing that.
>
Indeed, shrink_slab can only kill cached objects. They, however, are
usually a very big part of kernel memory. I wonder though if in case of
failure, it is worth it to try at least one shrink pass before you give up.
It is not very different from what is in memory-failure.c, except that
we could do better and do a more targetted shrinking (support for that
is being worked on)
^ permalink raw reply
* Re: [RFC PATCH powerpc ] Protect smp_processor_id() in arch_spin_unlock_wait()
From: Li Zhong @ 2013-01-10 7:50 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Paul Mackerras, Paul E. McKenney, PowerPC email list
In-Reply-To: <1357797726.4838.89.camel@pasglop>
On Thu, 2013-01-10 at 17:02 +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2012-11-19 at 14:16 +0800, Li Zhong wrote:
> > This patch tries to disable preemption for using smp_processor_id() in arch_spin_unlock_wait(),
> > to avoid following report:
>
> .../...
>
> > diff --git a/arch/powerpc/lib/locks.c b/arch/powerpc/lib/locks.c
> > index bb7cfec..7a7c31b 100644
> > --- a/arch/powerpc/lib/locks.c
> > +++ b/arch/powerpc/lib/locks.c
> > @@ -72,8 +72,10 @@ void arch_spin_unlock_wait(arch_spinlock_t *lock)
> > {
> > while (lock->slock) {
> > HMT_low();
> > + preempt_disable();
> > if (SHARED_PROCESSOR)
> > __spin_yield(lock);
> > + preempt_enable();
> > }
>
> I assume what you are protecting is the PACA access in SHARED_PROCESSOR
> or is there more ?
Yes, only the one in SHARED_PROCESSOR.
>
> In that case I'd say just make it use local_paca-> directly or something
> like that. It doesn't matter if the access is racy, all processors will
> have the same value for that field as far as I can tell.
It also seemed to me that all processors have the same value :). I'll
send an updated version based on your suggestion soon.
Thanks, Zhong
>
> Cheers,
> Ben.
>
>
^ permalink raw reply
* Re: [PATCH v6 00/15] memory-hotplug: hot-remove physical memory
From: Kamezawa Hiroyuki @ 2013-01-10 7:31 UTC (permalink / raw)
To: Glauber Costa
Cc: linux-ia64, linux-sh, Tang Chen, linux-mm, paulus, hpa,
sparclinux, cl, linux-s390, x86, linux-acpi, isimatu.yasuaki,
linfeng, mgorman, kosaki.motohiro, rientjes, len.brown, wency,
cmetcalf, wujianguo, yinghai, laijs, linux-kernel, minchan.kim,
Andrew Morton, linuxppc-dev
In-Reply-To: <50EE6A48.7060307@parallels.com>
(2013/01/10 16:14), Glauber Costa wrote:
> On 01/10/2013 06:17 AM, Tang Chen wrote:
>>>> Note: if the memory provided by the memory device is used by the
>>>> kernel, it
>>>> can't be offlined. It is not a bug.
>>>
>>> Right. But how often does this happen in testing? In other words,
>>> please provide an overall description of how well memory hot-remove is
>>> presently operating. Is it reliable? What is the success rate in
>>> real-world situations?
>>
>> We test the hot-remove functionality mostly with movable_online used.
>> And the memory used by kernel is not allowed to be removed.
>
> Can you try doing this using cpusets configured to hardwall ?
> It is my understanding that the object allocators will try hard not to
> allocate anything outside the walls defined by cpuset. Which means that
> if you have one process per node, and they are hardwalled, your kernel
> memory will be spread evenly among the machine. With a big enough load,
> they should eventually be present in all blocks.
>
I'm sorry I couldn't catch your point.
Do you want to confirm whether cpuset can work enough instead of ZONE_MOVABLE ?
Or Do you want to confirm whether ZONE_MOVABLE will not work if it's used with cpuset ?
> Another question I have for you: Have you considering calling
> shrink_slab to try to deplete the caches and therefore free at least
> slab memory in the nodes that can't be offlined? Is it relevant?
>
At this stage, we don't consider to call shrink_slab(). We require
nearly 100% success at offlining memory for removing DIMM.
It's my understanding.
IMHO, I don't think shrink_slab() can kill all objects in a node even
if they are some caches. We need more study for doing that.
Thanks,
-Kame
^ permalink raw reply
* Re: [PATCH v6 00/15] memory-hotplug: hot-remove physical memory
From: Glauber Costa @ 2013-01-10 7:14 UTC (permalink / raw)
To: Tang Chen
Cc: linux-ia64, linux-sh, linux-mm, paulus, hpa, sparclinux, cl,
linux-s390, x86, linux-acpi, isimatu.yasuaki, linfeng, mgorman,
kosaki.motohiro, rientjes, len.brown, wency, cmetcalf, wujianguo,
yinghai, laijs, linux-kernel, minchan.kim, Andrew Morton,
linuxppc-dev
In-Reply-To: <50EE24A4.8020601@cn.fujitsu.com>
On 01/10/2013 06:17 AM, Tang Chen wrote:
>>> Note: if the memory provided by the memory device is used by the
>>> kernel, it
>>> can't be offlined. It is not a bug.
>>
>> Right. But how often does this happen in testing? In other words,
>> please provide an overall description of how well memory hot-remove is
>> presently operating. Is it reliable? What is the success rate in
>> real-world situations?
>
> We test the hot-remove functionality mostly with movable_online used.
> And the memory used by kernel is not allowed to be removed.
Can you try doing this using cpusets configured to hardwall ?
It is my understanding that the object allocators will try hard not to
allocate anything outside the walls defined by cpuset. Which means that
if you have one process per node, and they are hardwalled, your kernel
memory will be spread evenly among the machine. With a big enough load,
they should eventually be present in all blocks.
Another question I have for you: Have you considering calling
shrink_slab to try to deplete the caches and therefore free at least
slab memory in the nodes that can't be offlined? Is it relevant?
^ permalink raw reply
* [PATCH] powerpc: Make room in exception vector area
From: Benjamin Herrenschmidt @ 2013-01-10 6:45 UTC (permalink / raw)
To: linuxppc-dev
The FWNMI region is fixed at 0x7000 and the vector are now
overflowing that with some configurations. Fix that by moving
some hash management code out of that region as it doesn't need
to be that close to the call sites (isn't accessed using
conditional branches).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/kernel/exceptions-64s.S | 110 +++++++++++++++++-----------------
1 file changed, 55 insertions(+), 55 deletions(-)
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index a28a65f..7a1c87c 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -1180,6 +1180,61 @@ END_FTR_SECTION_IFSET(CPU_FTR_VSX)
.globl __end_handlers
__end_handlers:
+ /* Equivalents to the above handlers for relocation-on interrupt vectors */
+ STD_RELON_EXCEPTION_HV(., 0xe00, h_data_storage)
+ KVM_HANDLER(PACA_EXGEN, EXC_HV, 0xe00)
+ STD_RELON_EXCEPTION_HV(., 0xe20, h_instr_storage)
+ KVM_HANDLER(PACA_EXGEN, EXC_HV, 0xe20)
+ STD_RELON_EXCEPTION_HV(., 0xe40, emulation_assist)
+ KVM_HANDLER(PACA_EXGEN, EXC_HV, 0xe40)
+ STD_RELON_EXCEPTION_HV(., 0xe60, hmi_exception)
+ KVM_HANDLER(PACA_EXGEN, EXC_HV, 0xe60)
+ MASKABLE_RELON_EXCEPTION_HV(., 0xe80, h_doorbell)
+ KVM_HANDLER(PACA_EXGEN, EXC_HV, 0xe80)
+
+ STD_RELON_EXCEPTION_PSERIES(., 0xf00, performance_monitor)
+ STD_RELON_EXCEPTION_PSERIES(., 0xf20, altivec_unavailable)
+ STD_RELON_EXCEPTION_PSERIES(., 0xf40, vsx_unavailable)
+
+#if defined(CONFIG_PPC_PSERIES) || defined(CONFIG_PPC_POWERNV)
+/*
+ * Data area reserved for FWNMI option.
+ * This address (0x7000) is fixed by the RPA.
+ */
+ .= 0x7000
+ .globl fwnmi_data_area
+fwnmi_data_area:
+
+ /* pseries and powernv need to keep the whole page from
+ * 0x7000 to 0x8000 free for use by the firmware
+ */
+ . = 0x8000
+#endif /* defined(CONFIG_PPC_PSERIES) || defined(CONFIG_PPC_POWERNV) */
+
+/* Space for CPU0's segment table */
+ .balign 4096
+ .globl initial_stab
+initial_stab:
+ .space 4096
+
+#ifdef CONFIG_PPC_POWERNV
+_GLOBAL(opal_mc_secondary_handler)
+ HMT_MEDIUM_PPR_DISCARD
+ SET_SCRATCH0(r13)
+ GET_PACA(r13)
+ clrldi r3,r3,2
+ tovirt(r3,r3)
+ std r3,PACA_OPAL_MC_EVT(r13)
+ ld r13,OPAL_MC_SRR0(r3)
+ mtspr SPRN_SRR0,r13
+ ld r13,OPAL_MC_SRR1(r3)
+ mtspr SPRN_SRR1,r13
+ ld r3,OPAL_MC_GPR3(r3)
+ GET_SCRATCH0(r13)
+ b machine_check_pSeries
+#endif /* CONFIG_PPC_POWERNV */
+
+
/*
* Hash table stuff
*/
@@ -1373,58 +1428,3 @@ _GLOBAL(do_stab_bolted)
ld r13,PACA_EXSLB+EX_R13(r13)
rfid
b . /* prevent speculative execution */
-
-
- /* Equivalents to the above handlers for relocation-on interrupt vectors */
- STD_RELON_EXCEPTION_HV(., 0xe00, h_data_storage)
- KVM_HANDLER(PACA_EXGEN, EXC_HV, 0xe00)
- STD_RELON_EXCEPTION_HV(., 0xe20, h_instr_storage)
- KVM_HANDLER(PACA_EXGEN, EXC_HV, 0xe20)
- STD_RELON_EXCEPTION_HV(., 0xe40, emulation_assist)
- KVM_HANDLER(PACA_EXGEN, EXC_HV, 0xe40)
- STD_RELON_EXCEPTION_HV(., 0xe60, hmi_exception)
- KVM_HANDLER(PACA_EXGEN, EXC_HV, 0xe60)
- MASKABLE_RELON_EXCEPTION_HV(., 0xe80, h_doorbell)
- KVM_HANDLER(PACA_EXGEN, EXC_HV, 0xe80)
-
- STD_RELON_EXCEPTION_PSERIES(., 0xf00, performance_monitor)
- STD_RELON_EXCEPTION_PSERIES(., 0xf20, altivec_unavailable)
- STD_RELON_EXCEPTION_PSERIES(., 0xf40, vsx_unavailable)
-
-#if defined(CONFIG_PPC_PSERIES) || defined(CONFIG_PPC_POWERNV)
-/*
- * Data area reserved for FWNMI option.
- * This address (0x7000) is fixed by the RPA.
- */
- .= 0x7000
- .globl fwnmi_data_area
-fwnmi_data_area:
-
- /* pseries and powernv need to keep the whole page from
- * 0x7000 to 0x8000 free for use by the firmware
- */
- . = 0x8000
-#endif /* defined(CONFIG_PPC_PSERIES) || defined(CONFIG_PPC_POWERNV) */
-
-/* Space for CPU0's segment table */
- .balign 4096
- .globl initial_stab
-initial_stab:
- .space 4096
-
-#ifdef CONFIG_PPC_POWERNV
-_GLOBAL(opal_mc_secondary_handler)
- HMT_MEDIUM_PPR_DISCARD
- SET_SCRATCH0(r13)
- GET_PACA(r13)
- clrldi r3,r3,2
- tovirt(r3,r3)
- std r3,PACA_OPAL_MC_EVT(r13)
- ld r13,OPAL_MC_SRR0(r3)
- mtspr SPRN_SRR0,r13
- ld r13,OPAL_MC_SRR1(r3)
- mtspr SPRN_SRR1,r13
- ld r3,OPAL_MC_GPR3(r3)
- GET_SCRATCH0(r13)
- b machine_check_pSeries
-#endif /* CONFIG_PPC_POWERNV */
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox