[PATCH] ACPI based Memory Hotplug Driver Patch

[PATCH] ACPI based Memory Hotplug Driver Patch

[S, Naveen B]

Hi,

Attached is an ACPI based hot plug driver patch to support physical memory hotplug. This driver supports physical hotplug operation on memory, fields notifications from firmware and notifies the VM of the affected memory ranges.  The following patch is against kernel 2.6.8.1-mm3, and works with the current memory hotplug VM patches posted at: http://sprucegoose.sr71.net/patches.  This patch has been tested on real prototype hardware in the hot-add memory case. Hot remove feature is tested in an emulated environment (by overriding ACPI DSDT). 

Please review and consider for inclusion. 

Thanks & Regards


Signed-off-by: Naveen B S <naveen.b.s-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Signed-off-by: Matt Tolentino <matthew.e.tolentino-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

 drivers/acpi/Kconfig      |    7 
 drivers/acpi/Makefile     |    1 
 drivers/acpi/acpi_ksyms.c |    1 
 drivers/acpi/memory.c     |  576 ++++++++++++++++++++++++++++++++++++++++++++++
 drivers/acpi/scan.c       |    2 
 include/acpi/acpi_bus.h   |    2 
 6 files changed, 588 insertions(+), 1 deletion(-)


diff -Nura linux-2.6.8.1-mm3-orig/drivers/acpi/acpi_ksyms.c linux-2.6.8.1-mm3-hpmem/drivers/acpi/acpi_ksyms.c
--- linux-2.6.8.1-mm3-orig/drivers/acpi/acpi_ksyms.c	2004-09-09 13:55:36.000000000 +0530
+++ linux-2.6.8.1-mm3-hpmem/drivers/acpi/acpi_ksyms.c	2004-09-09 14:01:11.000000000 +0530
@@ -135,6 +135,7 @@
 EXPORT_SYMBOL(acpi_bus_receive_event);
 EXPORT_SYMBOL(acpi_bus_register_driver);
 EXPORT_SYMBOL(acpi_bus_unregister_driver);
+EXPORT_SYMBOL(acpi_bus_add);
 
 #endif /*CONFIG_ACPI_BUS*/
 
diff -Nura linux-2.6.8.1-mm3-orig/drivers/acpi/Kconfig linux-2.6.8.1-mm3-hpmem/drivers/acpi/Kconfig
--- linux-2.6.8.1-mm3-orig/drivers/acpi/Kconfig	2004-09-09 13:55:36.000000000 +0530
+++ linux-2.6.8.1-mm3-hpmem/drivers/acpi/Kconfig	2004-09-09 14:01:11.000000000 +0530
@@ -270,5 +270,12 @@
 	  kernel logs, and/or you are using this on a notebook which
 	  does not yet have an HPET, you should say "Y" here.
 
+config ACPI_HOTPLUG_MEMORY
+	tristate "Memory Hotplug"
+	depends on ACPI
+	depends on MEMORY_HOTPLUG
+	default m
+	help
+	  This driver adds supports for ACPI Memory Hotplug.
 endmenu
 
diff -Nura linux-2.6.8.1-mm3-orig/drivers/acpi/Makefile linux-2.6.8.1-mm3-hpmem/drivers/acpi/Makefile
--- linux-2.6.8.1-mm3-orig/drivers/acpi/Makefile	2004-09-09 13:55:36.000000000 +0530
+++ linux-2.6.8.1-mm3-hpmem/drivers/acpi/Makefile	2004-09-09 14:01:11.000000000 +0530
@@ -48,3 +48,4 @@
 obj-$(CONFIG_ACPI_ASUS)		+= asus_acpi.o
 obj-$(CONFIG_ACPI_TOSHIBA)	+= toshiba_acpi.o
 obj-$(CONFIG_ACPI_BUS)		+= scan.o motherboard.o
+obj-$(CONFIG_ACPI_HOTPLUG_MEMORY)	+= memory.o
diff -Nura linux-2.6.8.1-mm3-orig/drivers/acpi/memory.c linux-2.6.8.1-mm3-hpmem/drivers/acpi/memory.c
--- linux-2.6.8.1-mm3-orig/drivers/acpi/memory.c	1970-01-01 05:30:00.000000000 +0530
+++ linux-2.6.8.1-mm3-hpmem/drivers/acpi/memory.c	2004-09-09 14:01:47.000000000 +0530
@@ -0,0 +1,576 @@
+/*
+ * Copyright (C) 2004 Intel Corporation <naveen.b.s-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
+ *
+ * All rights reserved.
+ *
+ * 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, GOOD TITLE or
+ * NON INFRINGEMENT.  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., 675 Mass Ave, Cambridge, MA 02139, USA.
+ *
+ *
+ * ACPI based HotPlug driver that supports Memory Hotplug 
+ * This driver fields notifications from firmare for memory add
+ * and remove operations and alerts the VM of the affected memory
+ * ranges.  
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/types.h>
+#include <linux/memory_hotplug.h>
+#include <acpi/acpi_drivers.h>
+
+
+#define ACPI_MEMORY_DEVICE_COMPONENT		0x08000000UL
+#define ACPI_MEMORY_DEVICE_CLASS		"memory"
+#define ACPI_MEMORY_DEVICE_HID			"PNP0C80"
+#define ACPI_MEMORY_DEVICE_DRIVER_NAME		"Hotplug Mem Driver"
+#define ACPI_MEMORY_DEVICE_NAME			"Hotplug Mem Device"
+
+#define _COMPONENT		ACPI_MEMORY_DEVICE_COMPONENT
+
+ACPI_MODULE_NAME		("acpi_memory")
+MODULE_AUTHOR("Naveen B S <naveen.b.s-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>");
+MODULE_DESCRIPTION(ACPI_MEMORY_DEVICE_DRIVER_NAME);
+MODULE_LICENSE("GPL");
+
+/* ACPI _STA method values */
+#define ACPI_MEMORY_STA_PRESENT		(0x00000001UL)
+#define ACPI_MEMORY_STA_ENABLED		(0x00000002UL)
+#define ACPI_MEMORY_STA_FUNCTIONAL	(0x00000008UL)
+
+/* Memory Device States */
+#define MEMORY_INVALID_STATE	0
+#define MEMORY_POWER_ON_STATE	1
+#define MEMORY_POWER_OFF_STATE	2
+
+static int acpi_memory_device_add (struct acpi_device *device);
+static int acpi_memory_device_remove (struct acpi_device *device, int type);
+
+static struct acpi_driver acpi_memory_device_driver = {
+	.name =		ACPI_MEMORY_DEVICE_DRIVER_NAME,
+	.class =	ACPI_MEMORY_DEVICE_CLASS,
+	.ids =		ACPI_MEMORY_DEVICE_HID,
+	.ops =		{
+				.add =		acpi_memory_device_add,
+				.remove =	acpi_memory_device_remove,
+			},
+};
+
+struct acpi_memory_device {
+	acpi_handle handle;	
+	unsigned int state;		/* State of the memory device */
+	unsigned short cache_attribute;	/* memory cache attribute */
+	unsigned short read_write_attribute;/* memory read/write attribute */
+	u64 start_addr;	/* Memory Range start physical addr */
+	u64 end_addr;	/* Memory Range end physical addr */
+};
+
+
+static int 
+acpi_memory_get_device_resources(struct acpi_memory_device *mem_device) 
+{
+	acpi_status status;
+	struct acpi_buffer buffer = {ACPI_ALLOCATE_BUFFER, NULL};	
+	struct acpi_resource *resource = NULL;
+	struct acpi_resource_address16 *address16 = NULL;
+	struct acpi_resource_address32 *address32 = NULL;
+	struct acpi_resource_address64 *address64 = NULL;
+
+	ACPI_FUNCTION_TRACE("acpi_memory_get_device_resources");
+
+	/* Get the range from the _CRS */
+	status = acpi_get_current_resources(mem_device->handle, &buffer);
+	if (ACPI_FAILURE(status))
+		return_VALUE(-EINVAL);
+
+	resource = (struct acpi_resource *) buffer.pointer;
+		
+	switch (resource->id) {
+	case ACPI_RSTYPE_ADDRESS16:
+		address16 = (struct acpi_resource_address16 *) &resource->data;
+		if (address16->resource_type != ACPI_MEMORY_RANGE) 
+			break;
+
+		/* Populate the structure */
+		mem_device->cache_attribute = 
+			address16->attribute.memory.cache_attribute;
+		mem_device->read_write_attribute = 
+			address16->attribute.memory.read_write_attribute;
+		mem_device->start_addr = address16->min_address_range;
+		mem_device->end_addr = address16->max_address_range;
+		break;
+
+	case ACPI_RSTYPE_ADDRESS32:
+		address32 = (struct acpi_resource_address32 *) &resource->data;
+		if (address32->resource_type != ACPI_MEMORY_RANGE) 
+			break;
+		
+		/* Populate the structure */
+		mem_device->cache_attribute = 
+			address32->attribute.memory.cache_attribute;
+		mem_device->read_write_attribute = 
+			address32->attribute.memory.read_write_attribute;
+		mem_device->start_addr = address32->min_address_range;
+		mem_device->end_addr = address32->max_address_range;
+		break;
+		
+	case ACPI_RSTYPE_ADDRESS64:
+		address64 = (struct acpi_resource_address64 *) &resource->data;
+		if (address64->resource_type != ACPI_MEMORY_RANGE) 
+			break;
+
+		/* Populate the structure */
+		mem_device->cache_attribute = 
+			address64->attribute.memory.cache_attribute;
+		mem_device->read_write_attribute = 
+			address64->attribute.memory.read_write_attribute;
+		mem_device->start_addr = address64->min_address_range;
+		mem_device->end_addr = address64->max_address_range;
+		break;
+
+	default:
+		break;
+	}
+
+	acpi_os_free(buffer.pointer);
+	return_VALUE(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;
+
+	ACPI_FUNCTION_TRACE("acpi_memory_get_device");
+
+	if (!acpi_bus_get_device(handle, &device) && device) 
+		goto end;
+	
+	status = acpi_get_parent(handle, &phandle);
+	if (ACPI_FAILURE(status)) {
+		ACPI_DEBUG_PRINT((ACPI_DB_ERROR,
+			"Error in acpi_get_parent\n"));
+		return_VALUE(-EINVAL);
+	}
+
+	/* Get the parent device */
+	status = acpi_bus_get_device(phandle, &pdevice);
+	if (ACPI_FAILURE(status)) {
+		ACPI_DEBUG_PRINT((ACPI_DB_ERROR,
+			"Error in acpi_bus_get_device\n"));
+		return_VALUE(-EINVAL);
+	}
+	
+	/* 
+	 * Now add the notified device.  This creates the acpi_device 
+	 * and invokes .add function 
+	 */
+	status = acpi_bus_add(&device, pdevice, handle, ACPI_BUS_TYPE_DEVICE);
+	if (ACPI_FAILURE(status)) {
+		ACPI_DEBUG_PRINT((ACPI_DB_ERROR,
+			"Error in acpi_bus_add\n"));
+		return_VALUE(-EINVAL);
+	}
+
+end:
+	*mem_device = acpi_driver_data(device);
+	if (!(*mem_device)) {
+		printk(KERN_ERR "\n driver data not found" );
+		return_VALUE(-ENODEV);
+	}
+
+	return_VALUE(0);
+}
+
+static int 
+acpi_memory_check_device(struct acpi_memory_device *mem_device)
+{
+	unsigned long current_status;
+
+	ACPI_FUNCTION_TRACE("acpi_memory_check_device");
+
+	/* Get device present/absent information from the _STA */
+	if (ACPI_FAILURE(acpi_evaluate_integer(mem_device->handle, "_STA", 
+		NULL, &current_status)))
+		return_VALUE(-ENODEV);
+	/* 
+	 * Check for device status. Device should be 
+	 * present/enabled/functioning.
+	 */
+	if (!((current_status & ACPI_MEMORY_STA_PRESENT)
+		&& (current_status & ACPI_MEMORY_STA_ENABLED)
+		&& (current_status & ACPI_MEMORY_STA_FUNCTIONAL))) 
+		return_VALUE(-ENODEV);
+
+	return_VALUE(0);
+}
+
+static int 
+acpi_memory_enable_device(struct acpi_memory_device *mem_device)
+{
+	int result;
+	
+	ACPI_FUNCTION_TRACE("acpi_memory_enable_device");
+
+	/* Get the range from the _CRS */
+	result = acpi_memory_get_device_resources(mem_device); 
+	if (result) {
+		ACPI_DEBUG_PRINT((ACPI_DB_ERROR, 
+			"\nget_device_resources failed\n"));
+		mem_device->state = MEMORY_INVALID_STATE;		
+		return result;
+	}
+
+	/* 
+	 * Tell the VM there is more memory here...
+	 * Note: Assume that this function returns zero on success 
+	 */
+	result = add_memory(mem_device->start_addr, 
+			(mem_device->end_addr - mem_device->start_addr) + 1,
+			mem_device->read_write_attribute);
+	if (result) {
+		ACPI_DEBUG_PRINT((ACPI_DB_ERROR, 
+			"\nadd_memory failed\n"));
+		mem_device->state = MEMORY_INVALID_STATE;		
+		return result;
+	}
+
+	return result;
+}
+
+static int 
+acpi_memory_powerdown_device(struct acpi_memory_device *mem_device)
+{
+	acpi_status status;
+	struct acpi_object_list	arg_list;
+	union acpi_object arg;
+	unsigned long current_status;
+
+	ACPI_FUNCTION_TRACE("acpi_memory_powerdown_device");
+
+	/* Issue the _EJ0 command */
+	arg_list.count = 1;
+	arg_list.pointer = &arg;
+	arg.type = ACPI_TYPE_INTEGER;
+	arg.integer.value = 1;
+	status = acpi_evaluate_object(mem_device->handle, 
+			"_EJ0", &arg_list, NULL);
+	/* Return on _EJ0 failure */
+	if (ACPI_FAILURE(status)) {
+		ACPI_DEBUG_PRINT((ACPI_DB_ERROR,"_EJ0 failed.\n"));
+		return_VALUE(-ENODEV);		
+	}
+
+	/* Evalute _STA to check if the device is disabled */
+	status = acpi_evaluate_integer(mem_device->handle, "_STA", 
+		NULL, &current_status);
+	if (ACPI_FAILURE(status))
+		return_VALUE(-ENODEV);
+
+	/* Check for device status.  Device should be disabled */
+	if (current_status & ACPI_MEMORY_STA_ENABLED) 
+		return_VALUE(-EINVAL);
+
+	return_VALUE(0);
+}
+
+static int 
+acpi_memory_disable_device(struct acpi_memory_device *mem_device) 
+{
+	int result;
+
+	ACPI_FUNCTION_TRACE("acpi_memory_disable_device");
+
+	/* 
+	 * Ask the VM to offline this memory range.
+	 * Note: Assume that this function returns zero on success 
+	 */
+	if (remove_memory(mem_device->start_addr,
+		(mem_device->end_addr - mem_device->start_addr) + 1,
+		mem_device->read_write_attribute)) {
+		ACPI_DEBUG_PRINT((ACPI_DB_ERROR, "Hot-Remove failed.\n"));
+		return_VALUE(-EINVAL);	
+	}
+
+	/* Power-off and eject the device */
+	result = acpi_memory_powerdown_device(mem_device);	
+	if (result) { 
+		ACPI_DEBUG_PRINT((ACPI_DB_ERROR,
+					"Device Power Down failed.\n"));
+		/* Set the status of the device to invalid */
+		mem_device->state = MEMORY_INVALID_STATE;
+		return result;
+	}
+	
+	mem_device->state = MEMORY_POWER_OFF_STATE;
+	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;
+
+	ACPI_FUNCTION_TRACE("acpi_memory_device_notify");
+
+	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_DEBUG_PRINT((ACPI_DB_ERROR,
+				"Error in finding driver data\n"));
+			return_VOID;
+		}
+		
+		if (!acpi_memory_check_device(mem_device)) {
+			if (acpi_memory_enable_device(mem_device))
+				ACPI_DEBUG_PRINT((ACPI_DB_ERROR, 
+				"Error in acpi_memory_enable_device\n"));
+		}
+		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_DEBUG_PRINT((ACPI_DB_ERROR, 
+					"Device doesn't exist\n"));
+			break;
+		}
+		mem_device = acpi_driver_data(device);
+		if (!mem_device) {
+			ACPI_DEBUG_PRINT((ACPI_DB_ERROR, 
+					"Driver Data is NULL\n"));
+			break;
+		}
+	
+		/*
+		 * Currently disabling memory device from kernel mode
+		 * TBD: Can also be disabled from user mode scripts
+		 * TBD: Can also be disabled by Callback registration 
+		 * 	with generic sysfs driver
+		 */	
+		if (acpi_memory_disable_device(mem_device))
+			ACPI_DEBUG_PRINT((ACPI_DB_ERROR, 
+				"Error in acpi_memory_disable_device\n"));
+		/*
+		 * TBD: Invoke acpi_bus_remove to cleanup data structures
+		 */
+		break;
+	default:
+		ACPI_DEBUG_PRINT((ACPI_DB_INFO,
+			"Unsupported event [0x%x]\n", event));
+		break;
+	}
+
+	return_VOID;
+}
+
+static int
+acpi_memory_device_add(struct acpi_device *device)
+{
+	int result;
+	struct acpi_memory_device *mem_device = NULL;
+	
+	ACPI_FUNCTION_TRACE("acpi_memory_device_add");
+
+	if (!device)
+		return_VALUE(-EINVAL);
+
+	mem_device = kmalloc(sizeof(struct acpi_memory_device), GFP_KERNEL);
+	if (!mem_device)
+		return_VALUE(-ENOMEM);
+	memset(mem_device, 0, sizeof(struct acpi_memory_device));
+
+	mem_device->handle = device->handle;
+	sprintf(acpi_device_name(device), "%s", ACPI_MEMORY_DEVICE_NAME);
+	sprintf(acpi_device_class(device), "%s", ACPI_MEMORY_DEVICE_CLASS);
+	acpi_driver_data(device) = mem_device;
+
+	/* Get the range from the _CRS */
+	result = acpi_memory_get_device_resources(mem_device);
+	if (result) {
+		kfree(mem_device);
+		return_VALUE(result);
+	}
+		
+	/* Set the device state */
+	mem_device->state = MEMORY_POWER_ON_STATE;
+
+	printk(KERN_INFO "%s \n", acpi_device_name(device));
+
+	return_VALUE(result);
+}
+
+static int 
+acpi_memory_device_remove (struct acpi_device *device, int type)
+{
+	struct acpi_memory_device *mem_device = NULL;
+
+	ACPI_FUNCTION_TRACE("acpi_memory_device_remove");
+
+	if (!device || !acpi_driver_data(device))
+		return_VALUE(-EINVAL);
+	
+	mem_device = (struct acpi_memory_device *) acpi_driver_data(device);
+	kfree(mem_device);
+
+	return_VALUE(0);
+}
+
+/* 
+ * Helper function to check for memory device 
+ */
+static acpi_status is_memory_device(acpi_handle handle) 
+{
+	char *hardware_id;
+	acpi_status status;
+	struct acpi_buffer buffer = {ACPI_ALLOCATE_BUFFER, NULL};
+	struct acpi_device_info *info;
+	
+	ACPI_FUNCTION_TRACE("is_memory_device");
+
+	status = acpi_get_object_info(handle, &buffer);
+	if (ACPI_FAILURE(status)) 
+		return_ACPI_STATUS(AE_ERROR);
+	
+	info = buffer.pointer;
+	if (!(info->valid & ACPI_VALID_HID)) {
+		acpi_os_free(buffer.pointer);
+		return_ACPI_STATUS(AE_ERROR);
+	}
+	
+	hardware_id = info->hardware_id.value;
+	if ((hardware_id == NULL) || 
+		(strcmp(hardware_id, ACPI_MEMORY_DEVICE_HID))) 
+		status = AE_ERROR;
+	
+	acpi_os_free(buffer.pointer);
+	return_ACPI_STATUS(status);	
+}
+
+static acpi_status
+acpi_memory_register_notify_handler (acpi_handle handle, 
+	u32 level, void *ctxt, void **retv)
+{
+	acpi_status status;
+
+	ACPI_FUNCTION_TRACE("acpi_memory_register_notify_handler");
+	
+	status = is_memory_device(handle);
+	if (ACPI_FAILURE(status)) 
+		return_ACPI_STATUS(AE_OK);	/* continue */
+	
+	status = acpi_install_notify_handler(handle, ACPI_SYSTEM_NOTIFY, 
+			acpi_memory_device_notify, NULL);
+	if (ACPI_FAILURE(status)) {
+		ACPI_DEBUG_PRINT((ACPI_DB_ERROR,
+			"Error installing notify handler\n"));
+		return_ACPI_STATUS(AE_OK);	/* continue */
+	}
+		
+	return_ACPI_STATUS(status);	
+}
+
+static acpi_status
+acpi_memory_deregister_notify_handler (acpi_handle handle, 
+			       u32 level, void *ctxt, void **retv)
+{
+	acpi_status status;
+
+	ACPI_FUNCTION_TRACE("acpi_memory_deregister_notify_handler");
+	
+	status = is_memory_device(handle);
+	if (ACPI_FAILURE(status)) 
+		return_ACPI_STATUS(AE_OK);	/* continue */
+	
+	status = acpi_remove_notify_handler(handle,
+			ACPI_SYSTEM_NOTIFY, acpi_memory_device_notify);
+	if (ACPI_FAILURE(status)) {
+		ACPI_DEBUG_PRINT((ACPI_DB_ERROR,
+				"Error removing notify handler\n"));
+		return_ACPI_STATUS(AE_OK);	/* continue */
+	}
+	
+	return_ACPI_STATUS(status);	
+}
+
+static int __init
+acpi_memory_device_init (void)
+{
+	int result;
+	acpi_status status;
+
+	ACPI_FUNCTION_TRACE("acpi_memory_device_init");
+
+	result = acpi_bus_register_driver(&acpi_memory_device_driver);
+
+	if (result < 0) 
+		return_VALUE(-ENODEV);
+	
+	status = acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT, 
+				ACPI_UINT32_MAX,
+				acpi_memory_register_notify_handler, 
+				NULL, NULL);
+
+	if (ACPI_FAILURE (status)) {
+		ACPI_DEBUG_PRINT ((ACPI_DB_ERROR, "walk_namespace failed\n"));
+		acpi_bus_unregister_driver(&acpi_memory_device_driver);
+		return_VALUE(-ENODEV);
+        }
+
+	return_VALUE(0);
+}
+
+static void __exit
+acpi_memory_device_exit (void)
+{
+	acpi_status status;
+
+	ACPI_FUNCTION_TRACE("acpi_memory_device_exit");
+	
+	/* 
+	 * Adding this to un-install notification handlers for all the device
+	 * handles. 
+	 */
+	status = acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT, 
+			ACPI_UINT32_MAX,
+			acpi_memory_deregister_notify_handler, 
+			NULL, NULL);
+
+	if (ACPI_FAILURE (status)) 
+		ACPI_DEBUG_PRINT ((ACPI_DB_ERROR, "walk_namespace failed\n"));
+
+	acpi_bus_unregister_driver(&acpi_memory_device_driver);
+
+	return_VOID;
+}
+
+module_init(acpi_memory_device_init);
+module_exit(acpi_memory_device_exit);
+
+
diff -Nura linux-2.6.8.1-mm3-orig/drivers/acpi/scan.c linux-2.6.8.1-mm3-hpmem/drivers/acpi/scan.c
--- linux-2.6.8.1-mm3-orig/drivers/acpi/scan.c	2004-09-09 13:55:36.000000000 +0530
+++ linux-2.6.8.1-mm3-hpmem/drivers/acpi/scan.c	2004-09-09 14:01:11.000000000 +0530
@@ -760,7 +760,7 @@
 #endif /*CONFIG_ACPI_DEBUG_OUTPUT*/
 }
 
-static int 
+int 
 acpi_bus_add (
 	struct acpi_device	**child,
 	struct acpi_device	*parent,
diff -Nura linux-2.6.8.1-mm3-orig/include/acpi/acpi_bus.h linux-2.6.8.1-mm3-hpmem/include/acpi/acpi_bus.h
--- linux-2.6.8.1-mm3-orig/include/acpi/acpi_bus.h	2004-09-09 13:55:01.000000000 +0530
+++ linux-2.6.8.1-mm3-hpmem/include/acpi/acpi_bus.h	2004-09-09 14:01:11.000000000 +0530
@@ -321,6 +321,8 @@
 int acpi_bus_receive_event (struct acpi_bus_event *event);
 int acpi_bus_register_driver (struct acpi_driver *driver);
 int 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);
 
 int acpi_create_dir(struct acpi_device *);
 void acpi_remove_dir(struct acpi_device *);




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idP47&alloc_id\x10808&op=click

Re: [PATCH] ACPI based Memory Hotplug Driver Patch

[Dmitry Torokhov]

Hi,

On Thursday 09 September 2004 05:54 am, S, Naveen B wrote:

> +static int 
> +acpi_memory_get_device(acpi_handle handle,
> +       struct acpi_memory_device **mem_device) 
> +{

I think the above should go straight into drivers/acpi/bus.c - there is
nothing memory-specific in that code and having the common code for hot-
plugged devices would help other drivers. Umm.. yep. I see that ACPI
CPU hotplug posted just recently does exactly the same.

Also, does it compile as a module? acpi_bus_add does not seem to be
exported...


-- 
Dmitry


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idP47&alloc_id\x10808&op=click

Re: [Lhms-devel] [PATCH] ACPI based Memory Hotplug Driver Patch

[Dave Hansen]

On Thu, 2004-09-09 at 03:54, S, Naveen B wrote:
> Attached is an ACPI based hot plug driver patch to support physical
> memory hotplug. This driver supports physical hotplug operation on
> memory, fields notifications from firmware and notifies the VM of the
> affected memory ranges.  The following patch is against kernel
> 2.6.8.1-mm3, and works with the current memory hotplug VM patches
> posted at: http://sprucegoose.sr71.net/patches.  This patch has been
> tested on real prototype hardware in the hot-add memory case. Hot
> remove feature is tested in an emulated environment (by overriding
> ACPI DSDT). 
> 
> Please review and consider for inclusion. 

Very cool!  A few comments below.

> +config ACPI_HOTPLUG_MEMORY
> +	tristate "Memory Hotplug"
> +	depends on ACPI
> +	depends on MEMORY_HOTPLUG
> +	default m
> +	help
> +	  This driver adds supports for ACPI Memory Hotplug.
>  endmenu
...
> +obj-$(CONFIG_ACPI_HOTPLUG_MEMORY)	+= memory.o

What does this end up naming the module?  If it ends up being memory.o,
you might want to think about making it something a bit more
descriptive.  Does it even need to be allowed to be a module, or is that
standard ACPI practice?

> +static int 
> +acpi_memory_disable_device(struct acpi_memory_device *mem_device) 
> +{
> +	int result;
> +
> +	ACPI_FUNCTION_TRACE("acpi_memory_disable_device");
> +
> +	/* 
> +	 * Ask the VM to offline this memory range.
> +	 * Note: Assume that this function returns zero on success 
> +	 */
> +	if (remove_memory(mem_device->start_addr,
> +		(mem_device->end_addr - mem_device->start_addr) + 1,
> +		mem_device->read_write_attribute)) {
> +		ACPI_DEBUG_PRINT((ACPI_DB_ERROR, "Hot-Remove failed.\n"));
> +		return_VALUE(-EINVAL);	
> +	}
> +

How about actually passing up the value that remove_memory() gave back? 
Also, what's with the +1 on the size?

If it ends up that all of the callers of remove_memory() prefer to give
start and end addresses, we'll probably change the calling convention at
some point.  Whatever is most natural.

I think I'd slightly prefer something that looks more like this (same
thing goes for the add function): 

acpi_memory_disable_device(struct acpi_memory_device *mem_device) 
{
	int err;
	u64 start = mem_device->start_addr;
	u64 len = mem_device->end_addr - start + 1;
	unsigned long attr = mem_device->read_write_attribute;

	ACPI_FUNCTION_TRACE("acpi_memory_disable_device");

	/* 
	 * Ask the VM to offline this memory range.
	 */
	err = remove_memory(start, len, attr);

	if (err) {
		ACPI_DEBUG_PRINT((ACPI_DB_ERROR, "Hot-Remove failed.\n"));
		return_VALUE(err);	
	}
...

Otherwise, this looks very self-contained which, since we've given up on
ACPI code looking nice, is all we can ask for. :)

Other than the add/remove_memory() calls does this have any real
interaction with any non-ACPI code that I overlooked?

-- Dave



-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php

Re: [PATCH] ACPI based Memory Hotplug Driver Patch

[Bjorn Helgaas]

Nice work!

On Thursday 09 September 2004 4:54 am, S, Naveen B wrote:
> +acpi_memory_get_device_resources(struct acpi_memory_device *mem_device) 
> +{
> +	acpi_status status;
> +	struct acpi_buffer buffer = {ACPI_ALLOCATE_BUFFER, NULL};	
> +	struct acpi_resource *resource = NULL;
> +	struct acpi_resource_address16 *address16 = NULL;
> +	struct acpi_resource_address32 *address32 = NULL;
> +	struct acpi_resource_address64 *address64 = NULL;

You can use acpi_resource_to_address64() to keep from having to write
the same code for address16, address32, and address64.

> +	status = acpi_get_current_resources(mem_device->handle, &buffer);
> +	if (ACPI_FAILURE(status))
> +		return_VALUE(-EINVAL);
> +
> +	resource = (struct acpi_resource *) buffer.pointer;
> +		
> +	switch (resource->id) {
> +	case ACPI_RSTYPE_ADDRESS16:

I'm not sure you should assume the range will be the only item in _CRS
(i.e., you may need to iterate over all items using acpi_walk_resources()).

> +static int 
> +acpi_memory_check_device(struct acpi_memory_device *mem_device)

Could you just use acpi_bus_get_status() instead of defining this?

> +static int 
> +acpi_memory_powerdown_device(struct acpi_memory_device *mem_device)
> +{
> + ...
> +	/* Evalute _STA to check if the device is disabled */
> +	status = acpi_evaluate_integer(mem_device->handle, "_STA", 
> +		NULL, &current_status);

acpi_bus_get_status() again?

> +static acpi_status is_memory_device(acpi_handle handle)

(Different indent style).  Seems like this should check _CID as well
as _HID?  Could it leverage acpi_match_ids() somehow?


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php

Re: [PATCH] ACPI based Memory Hotplug Driver Patch

[Keiichiro Tokunaga]

On Thu, 09 Sep 2004 16:24:46 +0530 S, Naveen B wrote:
> Attached is an ACPI based hot plug driver patch to support physical
> memory hotplug. This driver supports physical hotplug operation on
> memory, fields notifications from firmware and notifies the VM of the
> affected memory ranges.  The following patch is against kernel
> 2.6.8.1-mm3, and works with the current memory hotplug VM patches
> posted at: http://sprucegoose.sr71.net/patches.  This patch has been
> tested on real prototype hardware in the hot-add memory case. Hot
> remove feature is tested in an emulated environment (by overriding
> ACPI DSDT). 
> 
> Please review and consider for inclusion. 

This is nice:)  I would like to suggest just one thing.

'acpi_memory_enable/disable_device()' seem to call generic
(not ACPI specific) hotplug functions 'add/remove_memory()' directly.
I think the generic hotplug functions should not be called directly
inside kernel, but from the userland for two reasons.

One reason is:  ACPI based CPU hotplug takes a different approach.
ACPI based CPU hotplug is assuming to have its user mode agent
script (maybe, 'cpu.agent'?).  This agent is to inovke the generic
hotplug functions via sysfs. (e.g. echo 0 > /sys/devices/system/cpu/cpu0/online)
ACPI based CPU hotplug issues /sbin/hotplug to invoke the agent
and does not call the generic hotplug functions directly inside kernel.
If ACPI based memory hotplug does not take the same approach,
ACPI based CPU and memory drivers have different approaches
to this.

Another reason is:  ACPI container driver is not assuming that
the generic memory hotplug function is called by ACPI based memory
driver directly.  ACPI container hotplug needs to invoke the generic CPU
and memory hotplug functions.  For this, it uses its agent 'container.agent'
to call the functions as well as CPU hotplug.  This is because that it would
be more flexible than doing everything inside kernel.  With this approach,
'container.agent' can have a policy for container hotplug (e.g. invocation
order of the generic hotplug functions, error policy, etc)  Actually, this
approach was recommended by community people when I posted the
first patches of the container driver.  if ACPI memory hotplug calls the
generic memory hotplug function directly inside kernel, this story would
be broken.

Can you consider this?

Thanks,
Keiichiro Tokunaga


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php

Re: [Lhms-devel] Re: [PATCH] ACPI based Memory Hotplug Driver Patch

[Hirokazu Takahashi]

Hello,

> > Attached is an ACPI based hot plug driver patch to support physical
> > memory hotplug. This driver supports physical hotplug operation on
> > memory, fields notifications from firmware and notifies the VM of the
> > affected memory ranges.  The following patch is against kernel
> > 2.6.8.1-mm3, and works with the current memory hotplug VM patches
> > posted at: http://sprucegoose.sr71.net/patches.  This patch has been
> > tested on real prototype hardware in the hot-add memory case. Hot
> > remove feature is tested in an emulated environment (by overriding
> > ACPI DSDT). 
> > 
> > Please review and consider for inclusion. 
> 
> This is nice:)  I would like to suggest just one thing.
> 
> 'acpi_memory_enable/disable_device()' seem to call generic
> (not ACPI specific) hotplug functions 'add/remove_memory()' directly.
> I think the generic hotplug functions should not be called directly
> inside kernel, but from the userland for two reasons.

And remove_memory() should be invoked from a process context,
as it would write-back data on the memory or would wait for
the memroy becoming freeable. It can't be removed as long as
there remain references to it.

It would cause weird problems if the function is called from an ACPI
handler directly.

Thank you,
Hirokazu Takahashi.


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php

Re: [Lhms-devel] Re: [PATCH] ACPI based Memory Hotplug Driver Patch

[Dave Hansen]

On Fri, 2004-09-10 at 23:08, Hirokazu Takahashi wrote:
> > 'acpi_memory_enable/disable_device()' seem to call generic
> > (not ACPI specific) hotplug functions 'add/remove_memory()' directly.
> > I think the generic hotplug functions should not be called directly
> > inside kernel, but from the userland for two reasons.
> 
> And remove_memory() should be invoked from a process context,
> as it would write-back data on the memory or would wait for
> the memroy becoming freeable. It can't be removed as long as
> there remain references to it.
> 
> It would cause weird problems if the function is called from an ACPI
> handler directly.

I don't think this is true.  It would be a problem if we were calling
sys_write() on the sysfs files from inside of there, but those
interfaces are *there* for firmware to call them.  

In fact, I think we even mention that where they're defined.  As long as
we claim that they might_sleep(), and ACPI isn't holding any locks at
the time, or in interrupt context, where's the problem?  Worst case, we
schedule_work() to have the removal done in a sleepable context.

-- Dave



-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php

Re: [PATCH] ACPI based Memory Hotplug Driver Patch

[Keiichiro Tokunaga]

On Thu, 09 Sep 2004 16:24:46 +0530 S, Naveen B wrote:
> Attached is an ACPI based hot plug driver patch to support physical
> memory hotplug. This driver supports physical hotplug operation on
> memory, fields notifications from firmware and notifies the VM of the
> affected memory ranges.  The following patch is against kernel
> 2.6.8.1-mm3, and works with the current memory hotplug VM patches
> posted at: http://sprucegoose.sr71.net/patches.  This patch has been
> tested on real prototype hardware in the hot-add memory case. Hot
> remove feature is tested in an emulated environment (by overriding
> ACPI DSDT). 
> 
> Please review and consider for inclusion. 

I would like to add a feature into drivers/acpi/memory.c.

Please see the patch below.  This patch is for the kernel applying
your patch.

This patch generates procfs entry 'info' for each memory ACPI
object to expose memory device information.  This information
is needed to determine which logical memory ID(s) (memsection ID)
belongs which memory ACPI object (e.g. memsection5 --> MEM0).
Memsection IDs could be fingured out from min_address_range
and max_address_range that 'info' file shows.

Actually, container hotplug is assuming to use the information,
because 'container.agent', which lives in the userland, needs
to search memsection entires related with a certain ACPI memory
object name (e.g. MEM0) to invoke generic memory hotplug function.

The 'info' file shows the following information.

kei%cat /proc/acpi/memory/MEM0/info
resource_type:               0x0
producer_consumer:           0x0
decode:                      0x0
min_address:                 0x0
max_address:                 0x0
granularity:                 0x0
min_address_range:           0x0
max_address_range:           0x80000000
address_translation_offset:  0x0
address_length:              0x80000000

Thanks,
Keiichiro Tokunaga


Signed-off-by: Keiichiro Tokunaga (tokunaga.keiich-+CUm20s59erQFUHtdCDX3A@public.gmane.org)
---

 linux-2.6.8.1-mm3-mem-kei/drivers/acpi/memory.c |  155 ++++++++++++++++++++++--
 1 files changed, 148 insertions(+), 7 deletions(-)

diff -puN drivers/acpi/memory.c~proc_memory drivers/acpi/memory.c
--- linux-2.6.8.1-mm3-mem/drivers/acpi/memory.c~proc_memory	2004-09-10 14:01:21.000000000 +0900
+++ linux-2.6.8.1-mm3-mem-kei/drivers/acpi/memory.c	2004-09-10 17:37:54.000000000 +0900
@@ -29,6 +29,8 @@
 #include <linux/module.h>
 #include <linux/init.h>
 #include <linux/types.h>
+#include <linux/proc_fs.h>
+#include <linux/seq_file.h>
 #include <linux/memory_hotplug.h>
 #include <acpi/acpi_drivers.h>
 
@@ -38,6 +40,8 @@
 #define ACPI_MEMORY_DEVICE_HID			"PNP0C80"
 #define ACPI_MEMORY_DEVICE_DRIVER_NAME		"Hotplug Mem Driver"
 #define ACPI_MEMORY_DEVICE_NAME			"Hotplug Mem Device"
+#define ACPI_MEMORY_DEVICE_FILE_INFO		"info"
+
 
 #define _COMPONENT		ACPI_MEMORY_DEVICE_COMPONENT
 
@@ -61,6 +65,7 @@ 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);
 void acpi_memory_device_notify(acpi_handle handle, u32 event, void *data);
+static int acpi_memory_info_open_fs(struct inode *inode, struct file *file);
 
 static struct acpi_driver acpi_memory_device_driver = {
 	.name =		ACPI_MEMORY_DEVICE_DRIVER_NAME,
@@ -79,11 +84,124 @@ struct acpi_memory_device {
 	unsigned short read_write_attribute;/* memory read/write attribute */
 	u64 start_addr;	/* Memory Range start physical addr */
 	u64 end_addr;	/* Memory Range end physical addr */
+	struct acpi_resource	resource;
 };
 
 #define to_memory_device(sys_device) container_of(sys_device, \
 					struct acpi_memory_device, sysdev)
 
+static struct file_operations acpi_memory_device_info_fops = {
+	.open 		= acpi_memory_info_open_fs,
+	.read		= seq_read,
+	.llseek		= seq_lseek,
+	.release	= single_release,
+};
+
+struct proc_dir_entry		*acpi_memory_device_dir = NULL;
+
+static int acpi_memory_info_seq_show(struct seq_file *seq, void *offset)
+{
+	struct acpi_memory_device *mem_device = (struct acpi_memory_device *)seq->private;
+	struct acpi_resource		*resource;
+	struct acpi_resource_address64	address64;
+
+	ACPI_FUNCTION_TRACE("acpi_memory_info_seq_show");
+
+	if (!mem_device)
+		goto end;
+
+	resource = &mem_device->resource;
+
+	/*
+	 * Even if the resource is an address16 or address32, or address64,
+	 * copy it to the adddress64 return buffer.
+	 */
+	acpi_resource_to_address64(resource, &address64);
+
+	if (address64.resource_type != ACPI_MEMORY_RANGE) {
+		goto end;
+	}
+
+	seq_printf(seq,
+		   "resource_type:               0x%x\n"
+		   "producer_consumer:           0x%x\n"
+		   "decode:                      0x%x\n"
+		   "min_address:                 0x%x\n"
+		   "max_address:                 0x%x\n"
+		   "granularity:                 0x%lx\n"
+		   "min_address_range:           0x%lx\n"
+		   "max_address_range:           0x%lx\n"
+		   "address_translation_offset:  0x%lx\n"
+		   "address_length:              0x%lx\n",
+		   address64.resource_type,
+		   address64.producer_consumer,
+		   address64.decode,
+		   address64.min_address_fixed,
+		   address64.max_address_fixed,
+		   address64.granularity,
+		   address64.min_address_range,
+		   address64.max_address_range,
+		   address64.address_translation_offset,
+		   address64.address_length);
+end:
+	return 0;
+}
+
+static int acpi_memory_info_open_fs(struct inode *inode, struct file *file)
+{
+	return single_open(file, acpi_memory_info_seq_show,
+			   PDE(inode)->data);
+}
+
+static int
+acpi_memory_add_fs (
+	struct acpi_device      *device)
+{
+	struct proc_dir_entry   *entry = NULL;
+
+	ACPI_FUNCTION_TRACE("acpi_memory_add_fs");
+
+	if (!acpi_device_dir(device)) {
+		acpi_device_dir(device) = proc_mkdir(acpi_device_bid(device),
+						     acpi_memory_device_dir);
+		if (!acpi_device_dir(device))
+			return_VALUE(-ENODEV);
+	}
+	acpi_device_dir(device)->owner = THIS_MODULE;
+
+	/* 'info' [R] */
+	entry = create_proc_entry(ACPI_MEMORY_DEVICE_FILE_INFO,
+				  S_IRUGO, acpi_device_dir(device));
+	if (!entry)
+		ACPI_DEBUG_PRINT((ACPI_DB_ERROR,
+				  "Unable to create '%s' fs entry\n",
+				  ACPI_MEMORY_DEVICE_FILE_INFO));
+	else {
+		entry->proc_fops = &acpi_memory_device_info_fops;
+		entry->data = acpi_driver_data(device);
+		entry->owner = THIS_MODULE;
+	}
+
+	return_VALUE(0);
+}
+
+static int
+acpi_memory_remove_fs (
+	struct acpi_device      *device)
+{
+	ACPI_FUNCTION_TRACE("acpi_memory_remove_fs");
+
+	if (acpi_device_dir(device)) {
+		remove_proc_entry(ACPI_MEMORY_DEVICE_FILE_INFO,
+				  acpi_device_dir(device));
+		remove_proc_entry(acpi_device_bid(device),
+				  acpi_memory_device_dir);
+		acpi_device_dir(device) = NULL;
+	}
+
+	return_VALUE(0);
+}
+
 static int 
 acpi_memory_get_device_resources(struct acpi_memory_device *mem_device) 
 {
@@ -102,6 +220,7 @@ acpi_memory_get_device_resources(struct 
 		return_VALUE(-EINVAL);
 
 	resource = (struct acpi_resource *) buffer.pointer;
+	mem_device->resource = *resource;
 		
 	switch (resource->id) {
 	case ACPI_RSTYPE_ADDRESS16:
@@ -409,16 +528,19 @@ acpi_memory_device_add(struct acpi_devic
 
 	/* Get the range from the _CRS */
 	result = acpi_memory_get_device_resources(mem_device);
-	if (result) {
-		kfree(mem_device);
-		return_VALUE(result);
-	}
+	if (result)
+		goto end;
 		
 	/* Set the device state */
 	mem_device->state = MEMORY_POWER_ON_STATE;
 
 	printk(KERN_INFO "%s \n", acpi_device_name(device));
 
+	/* procfs */
+	result = acpi_memory_add_fs(device);
+	if (result)
+		goto end;
+
 	status = acpi_install_notify_handler(mem_device->handle,
 		ACPI_SYSTEM_NOTIFY, acpi_memory_device_notify, mem_device);
 	if (ACPI_FAILURE(status)) {
@@ -428,6 +550,12 @@ acpi_memory_device_add(struct acpi_devic
 		kfree(mem_device);
 	}
 	
+end:
+	if (result) {
+		acpi_memory_remove_fs(device);
+		kfree(mem_device);
+	}
+
 	return_VALUE(result);
 }
 
@@ -442,6 +570,9 @@ acpi_memory_device_remove (struct acpi_d
 		return_VALUE(-EINVAL);
 	
 	mem_device = (struct acpi_memory_device *) acpi_driver_data(device);
+
+	acpi_memory_remove_fs(device);
+
 	kfree(mem_device);
 
 	return_VALUE(0);
@@ -531,11 +662,18 @@ acpi_memory_device_init (void)
 
 	ACPI_FUNCTION_TRACE("acpi_memory_device_init");
 
-	result = acpi_bus_register_driver(&acpi_memory_device_driver);
+	acpi_memory_device_dir = proc_mkdir(ACPI_MEMORY_DEVICE_CLASS,
+					    acpi_root_dir);
+	if (!acpi_memory_device_dir)
+		return_VALUE(-ENODEV);
+	acpi_memory_device_dir->owner = THIS_MODULE;
 
-	if (result < 0) 
+	result = acpi_bus_register_driver(&acpi_memory_device_driver);
+	if (result < 0) {
+		remove_proc_entry(ACPI_MEMORY_DEVICE_CLASS, acpi_root_dir);
 		return_VALUE(-ENODEV);
-	
+	}
+
 	status = acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT, 
 				ACPI_UINT32_MAX,
 				acpi_memory_register_notify_handler, 
@@ -543,6 +681,7 @@ acpi_memory_device_init (void)
 
 	if (ACPI_FAILURE (status)) {
 		ACPI_DEBUG_PRINT ((ACPI_DB_ERROR, "walk_namespace failed\n"));
+		remove_proc_entry(ACPI_MEMORY_DEVICE_CLASS, acpi_root_dir);
 		acpi_bus_unregister_driver(&acpi_memory_device_driver);
 		return_VALUE(-ENODEV);
         }
@@ -571,6 +710,8 @@ acpi_memory_device_exit (void)
 
 	acpi_bus_unregister_driver(&acpi_memory_device_driver);
 
+	remove_proc_entry(ACPI_MEMORY_DEVICE_CLASS, acpi_root_dir);
+
 	return_VOID;
 }
 

_


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php

Re: [Lhms-devel] Re: [PATCH] ACPI based Memory Hotplug Driver Patch

[Dave Hansen]

On Fri, 2004-09-10 at 07:02, Keiichiro Tokunaga wrote:
> On Thu, 09 Sep 2004 16:24:46 +0530 S, Naveen B wrote:
> > Attached is an ACPI based hot plug driver patch to support physical
> > memory hotplug. This driver supports physical hotplug operation on
> > memory, fields notifications from firmware and notifies the VM of the
> > affected memory ranges.  The following patch is against kernel
> > 2.6.8.1-mm3, and works with the current memory hotplug VM patches
> > posted at: http://sprucegoose.sr71.net/patches.  This patch has been
> > tested on real prototype hardware in the hot-add memory case. Hot
> > remove feature is tested in an emulated environment (by overriding
> > ACPI DSDT). 
> > 
> > Please review and consider for inclusion. 
> 
> I would like to add a feature into drivers/acpi/memory.c.
> 
> Please see the patch below.  This patch is for the kernel applying
> your patch.
> 
> This patch generates procfs entry 'info' for each memory ACPI
> object to expose memory device information.  This information
> is needed to determine which logical memory ID(s) (memsection ID)
> belongs which memory ACPI object (e.g. memsection5 --> MEM0).
> Memsection IDs could be fingured out from min_address_range
> and max_address_range that 'info' file shows.

At this point, adding stuff to /proc in mainline has a pretty slim
chance of happening.  sysfs is really the way to go, plus we already
have code in the mhp tree to export the hotplug memory controls via
sysfs.  This stuff seems to me to belong in /sys/firmware.

But, this brings up something that's been nagging me for a while: what
should /sys/devices/system/memory contain?  A logical view of memory for
use with memory hotplug, or a hardware description of memory?  I think
both are probably necessary, and should link to each other, but how
should we present them?

One thing that causes a problem is that ppc64 already exports a view of
its memory in /proc/device-tree.  But, I don't think this is something
that ACPI should perpetuate.  

-- Dave



-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php

Re: [Lhms-devel] Re: [PATCH] ACPI based Memory Hotplug Driver Patch

[Keiichiro Tokunaga]

On Fri, 10 Sep 2004 10:32:35 -0700 Dave Hansen wrote:
> On Fri, 2004-09-10 at 07:02, Keiichiro Tokunaga wrote:
> > On Thu, 09 Sep 2004 16:24:46 +0530 S, Naveen B wrote:
> > > Attached is an ACPI based hot plug driver patch to support physical
> > > memory hotplug. This driver supports physical hotplug operation on
> > > memory, fields notifications from firmware and notifies the VM of the
> > > affected memory ranges.  The following patch is against kernel
> > > 2.6.8.1-mm3, and works with the current memory hotplug VM patches
> > > posted at: http://sprucegoose.sr71.net/patches.  This patch has been
> > > tested on real prototype hardware in the hot-add memory case. Hot
> > > remove feature is tested in an emulated environment (by overriding
> > > ACPI DSDT). 
> > > 
> > > Please review and consider for inclusion. 
> > 
> > I would like to add a feature into drivers/acpi/memory.c.
> > 
> > Please see the patch below.  This patch is for the kernel applying
> > your patch.
> > 
> > This patch generates procfs entry 'info' for each memory ACPI
> > object to expose memory device information.  This information
> > is needed to determine which logical memory ID(s) (memsection ID)
> > belongs which memory ACPI object (e.g. memsection5 --> MEM0).
> > Memsection IDs could be fingured out from min_address_range
> > and max_address_range that 'info' file shows.
>
> At this point, adding stuff to /proc in mainline has a pretty slim
> chance of happening.  sysfs is really the way to go, plus we already
> have code in the mhp tree to export the hotplug memory controls via
> sysfs.  This stuff seems to me to belong in /sys/firmware.

Thanks for the comment:)

Okay, I agree with you.  

> But, this brings up something that's been nagging me for a while: what
> should /sys/devices/system/memory contain?  A logical view of memory for
> use with memory hotplug, or a hardware description of memory?  I think
> both are probably necessary, and should link to each other, but how
> should we present them?

How about this?

# ls /sys/firmware/acpi/memory/MEM1/
resource_type
producer_consumer
decode
min_address
max_address
granularity
min_address_range
max_address_range
address_translation_offset
address_length

# ls /sys/devices/system/memory/memsection4/
start_physaddr
<something else>

We can determine which memsection belongs to which ACPI
memory object by using min_address_range, max_address_range,
and start_physaddr.  In the above case, start_physaddr is between
min_address_range and max_address_range if MEM1 contains
memsection4.

Thanks,
Keiichiro Tokunaga


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php

Re: [Lhms-devel] Re: [PATCH] ACPI based Memory Hotplug Driver Patch

[Dave Hansen]

On Mon, 2004-09-13 at 01:23, Keiichiro Tokunaga wrote:
> On Fri, 10 Sep 2004 10:32:35 -0700 Dave Hansen wrote:
> > At this point, adding stuff to /proc in mainline has a pretty slim
> > chance of happening.  sysfs is really the way to go, plus we already
> > have code in the mhp tree to export the hotplug memory controls via
> > sysfs.  This stuff seems to me to belong in /sys/firmware.
> >
> > But, this brings up something that's been nagging me for a while: what
> > should /sys/devices/system/memory contain?  A logical view of memory for
> > use with memory hotplug, or a hardware description of memory?  I think
> > both are probably necessary, and should link to each other, but how
> > should we present them?
> 
> How about this?
> 
> # ls /sys/firmware/acpi/memory/MEM1/
> resource_type
> producer_consumer
> decode
> min_address
> max_address
> granularity
> min_address_range
> max_address_range
> address_translation_offset
> address_length

The placement looks right to me.

> # ls /sys/devices/system/memory/memsection4/
> start_physaddr
> <something else>
> 
> We can determine which memsection belongs to which ACPI
> memory object by using min_address_range, max_address_range,
> and start_physaddr.  In the above case, start_physaddr is between
> min_address_range and max_address_range if MEM1 contains
> memsection4.

sysfs really has a legacy of being linked together with regular old
symlinks.  There's plenty of stuff in there that we *could* derive by
looking all over the place, but don't because it's so easy to just
create links.  I say we create links from one to the other, and make
sure not to duplicate any information.  

For instance, there shouldn't really need to be a start_addr in the acpi
directory if it can easily be determined from the memsections that
belong to that acpi memory object.  (or the othe way around, maybe)

What we want to discourage is anybody writing ACPI-specific (or
OpenFirmware on ppc for that matter) memory hotplug applications when a
generic Linux one would do.  That might be impossible in the long run,
but it's worth a try.  

-- Dave



-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php

Re: [Lhms-devel] Re: [PATCH] ACPI based Memory Hotplug Driver Patch

[Keiichiro Tokunaga]

On Mon, 13 Sep 2004 01:41:05 -0700 Dave Hansen wrote:
> On Mon, 2004-09-13 at 01:23, Keiichiro Tokunaga wrote:
> > On Fri, 10 Sep 2004 10:32:35 -0700 Dave Hansen wrote:
> > > At this point, adding stuff to /proc in mainline has a pretty slim
> > > chance of happening.  sysfs is really the way to go, plus we already
> > > have code in the mhp tree to export the hotplug memory controls via
> > > sysfs.  This stuff seems to me to belong in /sys/firmware.
> > >
> > > But, this brings up something that's been nagging me for a while: what
> > > should /sys/devices/system/memory contain?  A logical view of memory for
> > > use with memory hotplug, or a hardware description of memory?  I think
> > > both are probably necessary, and should link to each other, but how
> > > should we present them?
> > 
> > How about this?
> > 
> > # ls /sys/firmware/acpi/memory/MEM1/
> > resource_type
> > producer_consumer
> > decode
> > min_address
> > max_address
> > granularity
> > min_address_range
> > max_address_range
> > address_translation_offset
> > address_length
> 
> The placement looks right to me.
> 
> > # ls /sys/devices/system/memory/memsection4/
> > start_physaddr
> > <something else>
> > 
> > We can determine which memsection belongs to which ACPI
> > memory object by using min_address_range, max_address_range,
> > and start_physaddr.  In the above case, start_physaddr is between
> > min_address_range and max_address_range if MEM1 contains
> > memsection4.
> 
> sysfs really has a legacy of being linked together with regular old
> symlinks.  There's plenty of stuff in there that we *could* derive by
> looking all over the place, but don't because it's so easy to just
> create links.  I say we create links from one to the other, and make
> sure not to duplicate any information.  
> 
> For instance, there shouldn't really need to be a start_addr in the acpi
> directory if it can easily be determined from the memsections that
> belong to that acpi memory object.  (or the othe way around, maybe)

Creating links from one to the other sounds fine.  But I don't think a
physical start address of an ACPI memory object can be detemined
from the memsections that belong to that object.  This is because
there is no gurantee that an ACPI memory object and a memsection
that belongs to the object always have the same start address.  So,
I think the interface to show physical memory range is necessary in
both the ACPI and memsection directory.

Thanks,
Keiichiro Tokunaga


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php

Re: [Lhms-devel] Re: [PATCH] ACPI based Memory Hotplug Driver Patch

[Dave Hansen]

On Mon, 2004-09-13 at 19:58, Keiichiro Tokunaga wrote:
> Creating links from one to the other sounds fine.  But I don't think a
> physical start address of an ACPI memory object can be detemined
> from the memsections that belong to that object.  This is because
> there is no gurantee that an ACPI memory object and a memsection
> that belongs to the object always have the same start address.  So,
> I think the interface to show physical memory range is necessary in
> both the ACPI and memsection directory.

I agree.  It's very possible that ACPI memory areas will be able to span
multiple memory sections, as the inverse.  

Although, I do wonder if we can have memory laid out in the firmware/
directory in some kind of firmware-agnostic way.  

What I want is to make sure that any hotplug memory application that is
written can use the same directories no matter whether it is a ppc
machine using OpenFirmware or an x86/ia64 machine using ACPI.  

Instead of just laying thing out in firmware/acpi, can we have another
directory that mirrors this information in the system/devices/
directory, but is identical across architectures?  

ppc64 guys, what do you think?

-- Dave



-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php

Re: [Lhms-devel] Re: [PATCH] ACPI based Memory Hotplug Driver Patch

[Keiichiro Tokunaga]

On Mon, 13 Sep 2004 21:11:44 -0700 Dave Hansen wrote:
> On Mon, 2004-09-13 at 19:58, Keiichiro Tokunaga wrote:
> > Creating links from one to the other sounds fine.  But I don't think a
> > physical start address of an ACPI memory object can be detemined
> > from the memsections that belong to that object.  This is because
> > there is no gurantee that an ACPI memory object and a memsection
> > that belongs to the object always have the same start address.  So,
> > I think the interface to show physical memory range is necessary in
> > both the ACPI and memsection directory.
> 
> I agree.  It's very possible that ACPI memory areas will be able to span
> multiple memory sections, as the inverse.  
> 
> Although, I do wonder if we can have memory laid out in the firmware/
> directory in some kind of firmware-agnostic way.  
> 
> What I want is to make sure that any hotplug memory application that is
> written can use the same directories no matter whether it is a ppc
> machine using OpenFirmware or an x86/ia64 machine using ACPI.  

That's an ideal solution that I like:)

> Instead of just laying thing out in firmware/acpi, can we have another
> directory that mirrors this information in the system/devices/
> directory, but is identical across architectures?  

That's an interesting idea.  I think that not all of the stuffs could
be identical across architectures, so we would lay architecture
specific sutffs only in architecture specific directory (e.g. /sys/firmware/acpi/),
and general stuffs (like physical address) in both the archtecture
specific directory and the mirror directory.  This sounds reasonable
to me.  By the way, where do you think would be a candidate for
the mirror directory?

Thanks,
Keiichiro Tokunaga


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php

Re: [Lhms-devel] Re: [PATCH] ACPI based Memory Hotplug Driver Patch

[Dave Hansen]

On Tue, 2004-09-14 at 02:29, Keiichiro Tokunaga wrote:
> On Mon, 13 Sep 2004 21:11:44 -0700 Dave Hansen wrote:
> > What I want is to make sure that any hotplug memory application that is
> > written can use the same directories no matter whether it is a ppc
> > machine using OpenFirmware or an x86/ia64 machine using ACPI.  
> 
> That's an ideal solution that I like:)
> 
> > Instead of just laying thing out in firmware/acpi, can we have another
> > directory that mirrors this information in the system/devices/
> > directory, but is identical across architectures?  
> 
> That's an interesting idea.  I think that not all of the stuffs could
> be identical across architectures, so we would lay architecture
> specific sutffs only in architecture specific directory (e.g. /sys/firmware/acpi/),
> and general stuffs (like physical address) in both the archtecture
> specific directory and the mirror directory.  This sounds reasonable
> to me.  By the way, where do you think would be a candidate for
> the mirror directory?

Well, in retrospect, I think that /sys/devices/system/memory is probably
a bad place for the hotplug controls to go.  It's really just a logical
view of the memory from Linux's perspective, and that somewhat takes a
back seat to the physical layout presented by the hardware.

So, perhaps the physical layout should go in /sys/devices/system/memory,
and we can put the hotplug controls in
/sys/devices/system/logical/memory, or something similar.  

-- Dave



-------------------------------------------------------
This SF.Net email is sponsored by: thawte's Crypto Challenge Vl
Crack the code and win a Sony DCRHC40 MiniDV Digital Handycam
Camcorder. More prizes in the weekly Lunch Hour Challenge.
Sign up NOW http://ad.doubleclick.net/clk;10740251;10262165;m

Re: [Lhms-devel] Re: [PATCH] ACPI based Memory Hotplug Driver Patch

[Keiichiro Tokunaga]

On Tue, 14 Sep 2004 10:12:16 -0700 Dave Hansen wrote:
> On Tue, 2004-09-14 at 02:29, Keiichiro Tokunaga wrote:
> > On Mon, 13 Sep 2004 21:11:44 -0700 Dave Hansen wrote:
> > > Instead of just laying thing out in firmware/acpi, can we have another
> > > directory that mirrors this information in the system/devices/
> > > directory, but is identical across architectures?  
> > 
> > That's an interesting idea.  I think that not all of the stuffs could
> > be identical across architectures, so we would lay architecture
> > specific sutffs only in architecture specific directory (e.g. /sys/firmware/acpi/),
> > and general stuffs (like physical address) in both the archtecture
> > specific directory and the mirror directory.  This sounds reasonable
> > to me.  By the way, where do you think would be a candidate for
> > the mirror directory?
> 
> Well, in retrospect, I think that /sys/devices/system/memory is probably
> a bad place for the hotplug controls to go.  It's really just a logical
> view of the memory from Linux's perspective, and that somewhat takes a
> back seat to the physical layout presented by the hardware.
> 
> So, perhaps the physical layout should go in /sys/devices/system/memory,
> and we can put the hotplug controls in
> /sys/devices/system/logical/memory, or something similar.  

Please let me make sure one thing.
Is this what you have in mind?

  /sys/devices/system/memory/  -->  physical layout
  /sys/devices/system/logical/memory/  -->  hotplug controls

By the way, I'm not sure what the 'hotplug controls' are.  Can you
be more specific about them?

Thanks,
Keiichiro Tokunaga


-------------------------------------------------------
This SF.Net email is sponsored by: thawte's Crypto Challenge Vl
Crack the code and win a Sony DCRHC40 MiniDV Digital Handycam
Camcorder. More prizes in the weekly Lunch Hour Challenge.
Sign up NOW http://ad.doubleclick.net/clk;10740251;10262165;m

Re: [Lhms-devel] Re: [PATCH] ACPI based Memory Hotplug Driver Patch

[Dave Hansen]

On Tue, 2004-09-14 at 17:08, Keiichiro Tokunaga wrote:
> Please let me make sure one thing.
> Is this what you have in mind?
> 
>   /sys/devices/system/memory/  -->  physical layout
>   /sys/devices/system/logical/memory/  -->  hotplug controls

Yeah, something like that.  

> By the way, I'm not sure what the 'hotplug controls' are.  Can you
> be more specific about them?

That's the place where Linux presents each memory section as well as the
'status' file so that each section may be added or removed from sysfs.

-- Dave



-------------------------------------------------------
This SF.Net email is sponsored by: thawte's Crypto Challenge Vl
Crack the code and win a Sony DCRHC40 MiniDV Digital Handycam
Camcorder. More prizes in the weekly Lunch Hour Challenge.
Sign up NOW http://ad.doubleclick.net/clk;10740251;10262165;m

Re: [Lhms-devel] Re: [PATCH] ACPI based Memory Hotplug Driver Patch

[Keiichiro Tokunaga]

On Tue, 14 Sep 2004 17:17:35 -0700 Dave Hansen wrote:
> On Tue, 2004-09-14 at 17:08, Keiichiro Tokunaga wrote:
> > Please let me make sure one thing.
> > Is this what you have in mind?
> > 
> >   /sys/devices/system/memory/  -->  physical layout
> >   /sys/devices/system/logical/memory/  -->  hotplug controls
> 
> Yeah, something like that.  
> 
> > By the way, I'm not sure what the 'hotplug controls' are.  Can you
> > be more specific about them?
> 
> That's the place where Linux presents each memory section as well as the
> 'status' file so that each section may be added or removed from sysfs.

Thanks.  Adding/removing directories of memsection from sysfs as
needed sounds nice to me:)

Okay, as a first try, I will be making a patch creating the directory
'/sys/firmware/acpi/memory/' and some entries.

Thanks,
Keiichiro Tokunaga


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

Re: [Lhms-devel] Re: [PATCH] ACPI based Memory Hotplug Driver Patch

[Joel Schopp]

> Although, I do wonder if we can have memory laid out in the firmware/
> directory in some kind of firmware-agnostic way.  
> 
> What I want is to make sure that any hotplug memory application that is
> written can use the same directories no matter whether it is a ppc
> machine using OpenFirmware or an x86/ia64 machine using ACPI.  

Noble goal, here is what we represent on ppc64 for a logical memory block.

bigbirdlp2:/proc/device-tree # ls ./memory\@10000000/
.  ..  device_type  ibm,my-drc-index  linux,phandle  name  reg
bigbirdlp2:/proc/device-tree/memory@10000000 # xxd ./reg
0000000: 0000 0000 1000 0000 0000 0000 1000 0000  ................
bigbirdlp2:/proc/device-tree/memory@10000000 # cat ./device_type
memory
bigbirdlp2:/proc/device-tree/memory@10000000 # xxd ./ibm,my-drc-index
0000000: 0000 0001                                ....
bigbirdlp2:/proc/device-tree/memory@10000000 # cat name
memory

I'm pretty sure the reg property is just a starting address, size pair. 
  The device type and name are pretty boring.  The drc-index is not 
guaranteed to correspond to anything (though it usually is start address 
/ size), you could call it arch-identifier or something.

> 
> Instead of just laying thing out in firmware/acpi, can we have another
> directory that mirrors this information in the system/devices/
> directory, but is identical across architectures?  

I'd do something like this for each LMB:

start-addr
size
arch-identifier


-------------------------------------------------------
This SF.Net email is sponsored by: thawte's Crypto Challenge Vl
Crack the code and win a Sony DCRHC40 MiniDV Digital Handycam
Camcorder. More prizes in the weekly Lunch Hour Challenge.
Sign up NOW http://ad.doubleclick.net/clk;10740251;10262165;m

[PATCH] /sys/firmware/acpi/memory/ for showing info of ACPI memory object

[Keiichiro Tokunaga]

On Fri, 10 Sep 2004 23:02:00 +0900 Keiichiro Tokunaga wrote:
> On Thu, 09 Sep 2004 16:24:46 +0530 S, Naveen B wrote:
> > Attached is an ACPI based hot plug driver patch to support physical
> > memory hotplug. This driver supports physical hotplug operation on
> > memory, fields notifications from firmware and notifies the VM of the
> > affected memory ranges.  The following patch is against kernel
> > 2.6.8.1-mm3, and works with the current memory hotplug VM patches
> > posted at: http://sprucegoose.sr71.net/patches.  This patch has been
> > tested on real prototype hardware in the hot-add memory case. Hot
> > remove feature is tested in an emulated environment (by overriding
> > ACPI DSDT). 
> > 
> > Please review and consider for inclusion. 
> 
> I would like to add a feature into drivers/acpi/memory.c.
> 
> Please see the patch below.  This patch is for the kernel applying
> your patch.

I have changed the patch to create directories and files in
/sys/firmware/acpi/memory/ from Dave's comments.  The files are
to export the following stuffs of each ACPI memory object for the
first version.

# ls /sys/firmware/acpi/memory/MEM1/
address_length
address_translation_offset
granularity
max_address_fixed
max_address_range
min_address_fixed
min_address_range
producer_consumer
resource_type

# cat /sys/firmware/acpi/memory/MEM1/min_address_range
0xc0000000

Naveen, if it looks okay, please include it to your patch.  If you are
still working on 2.6.8.1-mm3, it applies.  If you are not, please let
me know.

Thanks,
Keiichiro Tokunaga


Signed-off-by: Keiichiro Tokunaga <tokunaga.keiich-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
---

 drivers/acpi/memory.c |  363 +++++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 358 insertions(+), 5 deletions(-)

diff -puN drivers/acpi/memory.c~sysfs_memory drivers/acpi/memory.c
--- linux-2.6.8.1-mm3/drivers/acpi/memory.c~sysfs_memory	2004-09-16 10:19:00.000000000 +0900
+++ linux-2.6.8.1-mm3-kei/drivers/acpi/memory.c	2004-09-16 19:06:38.000000000 +0900
@@ -69,6 +69,15 @@ static struct acpi_driver acpi_memory_de
 			},
 };
 
+struct acpi_mem {
+	struct acpi_mem_device_ops	*ops;
+	void (*release)(struct acpi_mem *mdev);
+	struct kobject			kobj;
+};
+
+#define to_acpi_mem(n) container_of(n, struct acpi_mem, kobj)
+#define acpi_mem_to_dev(n) container_of(n, struct acpi_memory_device, amem)
+
 struct acpi_memory_device {
 	acpi_handle handle;	
 	unsigned int state;		/* State of the memory device */
@@ -76,8 +85,335 @@ struct acpi_memory_device {
 	unsigned short read_write_attribute;/* memory read/write attribute */
 	u64 start_addr;	/* Memory Range start physical addr */
 	u64 end_addr;	/* Memory Range end physical addr */
+	struct acpi_resource resource;
+	struct acpi_mem amem;
+};
+
+/*
+ * /sys/firmware/acpi/memory/
+ */
+struct acpi_mem_attribute {
+	struct attribute attr;
+	ssize_t (*show)(struct acpi_mem *, char *);
+	ssize_t (*store)(struct acpi_mem *, const char *, size_t);
 };
 
+#define to_acpi_mem_attr(n) container_of(n, struct acpi_mem_attribute, attr)
+
+static ssize_t acpi_mem_attr_show(struct kobject *kobj,
+				  struct attribute *attr, char *buf)
+{
+	struct acpi_mem *amem = to_acpi_mem(kobj);
+	struct acpi_mem_attribute *attribute = to_acpi_mem_attr(attr);
+	return attribute->show ? attribute->show(amem, buf) : 0;
+}
+
+static ssize_t acpi_mem_attr_store(struct kobject *kobj,
+				   struct attribute *attr, const char *buf,
+				   size_t len)
+{
+	struct acpi_mem *amem = to_acpi_mem(kobj);
+	struct acpi_mem_attribute *attribute = to_acpi_mem_attr(attr);
+	return attribute->store ? attribute->store(amem, buf, len) : 0;
+}
+
+static struct sysfs_ops acpi_mem_sysfs_ops = {
+	.show = acpi_mem_attr_show,
+	.store = acpi_mem_attr_store,
+};
+
+static void acpi_mem_release(struct kobject *kobj)
+{
+	sysfs_remove_dir(kobj);
+	if (kobj->kset) {
+		down_write(&kobj->kset->subsys->rwsem);
+		list_del_init(&kobj->entry);
+		up_write(&kobj->kset->subsys->rwsem);
+	}
+}
+
+static struct kobj_type acpi_mem_ktype = {
+	.sysfs_ops = &acpi_mem_sysfs_ops,
+	.release = &acpi_mem_release,
+};
+
+static decl_subsys_name(acpi_mem, memory, &acpi_mem_ktype, NULL);
+
+static int acpi_mem_register(struct acpi_mem *amem)
+{
+	return kobject_register(&amem->kobj);
+}
+
+int create_acpi_mem(struct acpi_memory_device *mem_device,
+			   struct acpi_device *device)
+{
+	int result;
+	struct acpi_mem *amem = &mem_device->amem;
+
+	ACPI_FUNCTION_TRACE("create_acpi_mem");
+
+	memset(amem, 0, sizeof(struct acpi_mem));
+	kobject_set_name(&amem->kobj, device->pnp.bus_id);
+	kobj_set_kset_s(amem, acpi_mem_subsys);
+	amem->kobj.parent = &acpi_mem_subsys.kset.kobj;
+
+	result = acpi_mem_register(amem);
+	if (result)
+		goto end;
+end:
+	return_VALUE(result);
+}
+
+int acpi_mem_fs_init(void)
+{
+	int result;
+	extern struct subsystem acpi_subsys;
+
+	ACPI_FUNCTION_TRACE("acpi_mem_fs_init");
+
+	acpi_mem_subsys.kset.kobj.parent = &acpi_subsys.kset.kobj;
+	result = subsystem_register(&acpi_mem_subsys);
+
+	return_VALUE(result);
+}
+
+void acpi_mem_fs_exit(void)
+{
+	ACPI_FUNCTION_TRACE("acpi_mem_fs_exit");
+
+	subsystem_unregister(&acpi_mem_subsys);
+
+	return_VOID;
+}
+
+static int get_address64(struct acpi_mem *amem,
+			 struct acpi_resource_address64 *address64)
+{
+	struct acpi_memory_device	*mem_device = acpi_mem_to_dev(amem);
+	struct acpi_resource		*resource;
+
+	if (!mem_device)
+		return -ENODEV;
+
+	resource = &mem_device->resource;
+
+	acpi_resource_to_address64(resource, address64);
+
+	if (address64->resource_type != ACPI_MEMORY_RANGE)
+		return -EINVAL;
+
+	return 0;
+}
+
+static ssize_t resource_type_read_file(struct acpi_mem *amem, char *buf)
+{
+	int result;
+	struct acpi_resource_address64 address64;
+
+	result = get_address64(amem, &address64);
+	if (result)
+		return result;
+
+	result = sprintf(buf, "0x%x\n", address64.resource_type);
+
+	return result;
+}
+
+static struct acpi_mem_attribute acpi_mem_attr_resource_type = {
+	.attr = {.name = "resource_type", .mode = S_IFREG | S_IRUGO},
+	.show = resource_type_read_file,
+};
+
+static ssize_t producer_consumer_read_file(struct acpi_mem *amem, char *buf)
+{
+	int result;
+	struct acpi_resource_address64 address64;
+
+	result = get_address64(amem, &address64);
+	if (result)
+		return result;
+
+	result = sprintf(buf, "0x%x\n", address64.producer_consumer);
+
+	return result;
+}
+
+static struct acpi_mem_attribute acpi_mem_attr_producer_consumer = {
+	.attr = {.name = "producer_consumer", .mode = S_IFREG | S_IRUGO},
+	.show = producer_consumer_read_file,
+};
+
+static ssize_t decode_read_file(struct acpi_mem *amem, char *buf)
+{
+	int result;
+	struct acpi_resource_address64 address64;
+
+	result = get_address64(amem, &address64);
+	if (result)
+		return result;
+
+	result = sprintf(buf, "0x%x\n", address64.decode);
+
+	return result;
+}
+
+static struct acpi_mem_attribute acpi_mem_attr_decode = {
+	.attr = {.name = "decode", .mode = S_IFREG | S_IRUGO},
+	.show = decode_read_file,
+};
+
+static ssize_t min_address_fixed_read_file(struct acpi_mem *amem, char *buf)
+{
+	int result;
+	struct acpi_resource_address64 address64;
+
+	result = get_address64(amem, &address64);
+	if (result)
+		return result;
+
+	result = sprintf(buf, "0x%x\n", address64.min_address_fixed);
+
+	return result;
+}
+
+static struct acpi_mem_attribute acpi_mem_attr_min_address_fixed = {
+	.attr = {.name = "min_address_fixed", .mode = S_IFREG | S_IRUGO},
+	.show = min_address_fixed_read_file,
+};
+
+static ssize_t max_address_fixed_read_file(struct acpi_mem *amem, char *buf)
+{
+	int result;
+	struct acpi_resource_address64 address64;
+
+	result = get_address64(amem, &address64);
+	if (result)
+		return result;
+
+	result = sprintf(buf, "0x%x\n", address64.max_address_fixed);
+
+	return result;
+}
+
+static struct acpi_mem_attribute acpi_mem_attr_max_address_fixed = {
+	.attr = {.name = "max_address_fixed", .mode = S_IFREG | S_IRUGO},
+	.show = max_address_fixed_read_file,
+};
+
+static ssize_t granularity_read_file(struct acpi_mem *amem, char *buf)
+{
+	int result;
+	struct acpi_resource_address64 address64;
+
+	result = get_address64(amem, &address64);
+	if (result)
+		return result;
+
+	result = sprintf(buf, "0x%llx\n", address64.granularity);
+
+	return result;
+}
+
+static struct acpi_mem_attribute acpi_mem_attr_granularity = {
+	.attr = {.name = "granularity", .mode = S_IFREG | S_IRUGO},
+	.show = granularity_read_file,
+};
+
+static ssize_t min_address_range_read_file(struct acpi_mem *amem, char *buf)
+{
+	int result;
+	struct acpi_resource_address64 address64;
+
+	result = get_address64(amem, &address64);
+	if (result)
+		return result;
+
+	result = sprintf(buf, "0x%llx\n", address64.min_address_range);
+
+	return result;
+}
+
+static struct acpi_mem_attribute acpi_mem_attr_min_address_range = {
+	.attr = {.name = "min_address_range", .mode = S_IFREG | S_IRUGO},
+	.show = min_address_range_read_file,
+};
+
+static ssize_t max_address_range_read_file(struct acpi_mem *amem, char *buf)
+{
+	int result;
+	struct acpi_resource_address64 address64;
+
+	result = get_address64(amem, &address64);
+	if (result)
+		return result;
+
+	result = sprintf(buf, "0x%llx\n", address64.max_address_range);
+
+	return result;
+}
+
+static struct acpi_mem_attribute acpi_mem_attr_max_address_range = {
+	.attr = {.name = "max_address_range", .mode = S_IFREG | S_IRUGO},
+	.show = max_address_range_read_file,
+};
+
+static ssize_t address_translation_offset_read_file(struct acpi_mem *amem,
+						    char *buf)
+{
+	int result;
+	struct acpi_resource_address64 address64;
+
+	result = get_address64(amem, &address64);
+	if (result)
+		return result;
+
+	result = sprintf(buf, "0x%llx\n",
+			 address64.address_translation_offset);
+
+	return result;
+}
+
+static struct acpi_mem_attribute acpi_mem_attr_address_translation_offset = {
+	.attr = {.name = "address_translation_offset",
+		 .mode = S_IFREG | S_IRUGO},
+	.show = address_translation_offset_read_file,
+};
+
+static ssize_t address_length_read_file(struct acpi_mem *amem, char *buf)
+{
+	int result;
+	struct acpi_resource_address64 address64;
+
+	result = get_address64(amem, &address64);
+	if (result)
+		return result;
+
+	result = sprintf(buf, "0x%llx\n", address64.address_length);
+
+	return result;
+}
+
+static struct acpi_mem_attribute acpi_mem_attr_address_length = {
+	.attr = {.name = "address_length", .mode = S_IFREG | S_IRUGO},
+	.show = address_length_read_file,
+};
+
+static int fs_add_memory(struct acpi_mem *amem)
+{
+	sysfs_create_file(&amem->kobj, &acpi_mem_attr_resource_type.attr);
+	sysfs_create_file(&amem->kobj, &acpi_mem_attr_producer_consumer.attr);
+	sysfs_create_file(&amem->kobj, &acpi_mem_attr_decode.attr);
+	sysfs_create_file(&amem->kobj, &acpi_mem_attr_min_address_fixed.attr);
+	sysfs_create_file(&amem->kobj, &acpi_mem_attr_max_address_fixed.attr);
+	sysfs_create_file(&amem->kobj, &acpi_mem_attr_granularity.attr);
+	sysfs_create_file(&amem->kobj, &acpi_mem_attr_min_address_range.attr);
+	sysfs_create_file(&amem->kobj, &acpi_mem_attr_max_address_range.attr);
+	sysfs_create_file(&amem->kobj,
+			  &acpi_mem_attr_address_translation_offset.attr);
+	sysfs_create_file(&amem->kobj, &acpi_mem_attr_address_length.attr);
+
+	return 0;
+}
 
 static int 
 acpi_memory_get_device_resources(struct acpi_memory_device *mem_device) 
@@ -97,6 +433,7 @@ acpi_memory_get_device_resources(struct 
 		return_VALUE(-EINVAL);
 
 	resource = (struct acpi_resource *) buffer.pointer;
+	mem_device->resource = *resource;
 		
 	switch (resource->id) {
 	case ACPI_RSTYPE_ADDRESS16:
@@ -413,17 +750,26 @@ acpi_memory_device_add(struct acpi_devic
 
 	/* Get the range from the _CRS */
 	result = acpi_memory_get_device_resources(mem_device);
-	if (result) {
-		kfree(mem_device);
-		return_VALUE(result);
-	}
-		
+	if (result)
+		goto errout;
+
+	result = create_acpi_mem(mem_device, device);
+	if (result)
+		goto errout;
+
+	result = fs_add_memory(&mem_device->amem);
+	if (result)
+		goto errout;
+
 	/* Set the device state */
 	mem_device->state = MEMORY_POWER_ON_STATE;
 
 	printk(KERN_INFO "%s \n", acpi_device_name(device));
 
 	return_VALUE(result);
+errout:
+	kfree(mem_device);
+	return_VALUE(result);
 }
 
 static int 
@@ -527,6 +873,10 @@ acpi_memory_device_init (void)
 
 	ACPI_FUNCTION_TRACE("acpi_memory_device_init");
 
+	result = acpi_mem_fs_init();
+	if (result)
+		return_VALUE(-ENODEV);
+
 	result = acpi_bus_register_driver(&acpi_memory_device_driver);
 
 	if (result < 0) 
@@ -540,6 +890,7 @@ acpi_memory_device_init (void)
 	if (ACPI_FAILURE (status)) {
 		ACPI_DEBUG_PRINT ((ACPI_DB_ERROR, "walk_namespace failed\n"));
 		acpi_bus_unregister_driver(&acpi_memory_device_driver);
+		acpi_mem_fs_exit();
 		return_VALUE(-ENODEV);
         }
 
@@ -567,6 +918,8 @@ acpi_memory_device_exit (void)
 
 	acpi_bus_unregister_driver(&acpi_memory_device_driver);
 
+	acpi_mem_fs_exit();
+
 	return_VOID;
 }
 

_


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

Re: [PATCH] /sys/firmware/acpi/memory/ for showing info of ACPI memory object

[Keiichiro Tokunaga]

On Thu, 16 Sep 2004 19:47:25 +0900 Keiichiro Tokunaga wrote:
> On Fri, 10 Sep 2004 23:02:00 +0900 Keiichiro Tokunaga wrote:
> > On Thu, 09 Sep 2004 16:24:46 +0530 S, Naveen B wrote:
> > > Attached is an ACPI based hot plug driver patch to support physical
> > > memory hotplug. This driver supports physical hotplug operation on
> > > memory, fields notifications from firmware and notifies the VM of the
> > > affected memory ranges.  The following patch is against kernel
> > > 2.6.8.1-mm3, and works with the current memory hotplug VM patches
> > > posted at: http://sprucegoose.sr71.net/patches.  This patch has been
> > > tested on real prototype hardware in the hot-add memory case. Hot
> > > remove feature is tested in an emulated environment (by overriding
> > > ACPI DSDT). 
> > > 
> > > Please review and consider for inclusion. 
> > 
> > I would like to add a feature into drivers/acpi/memory.c.
> > 
> > Please see the patch below.  This patch is for the kernel applying
> > your patch.
> 
> I have changed the patch to create directories and files in
> /sys/firmware/acpi/memory/ from Dave's comments.  The files are
> to export the following stuffs of each ACPI memory object for the
> first version.

I have updated the patch to show just information in real need.

  o min_address_range
  o max_address_range

This patch is still for 2.6.8.1-mm3.
Naveen, if I need to update the patch, please let me know.

Thanks,
Keiichiro Tokunaga

Name: sysfs_memory.patch
Status: Tested on 2.6.8.1-mm3
Signed-off-by: Keiichiro Tokunaga <tokunaga.keiich-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
Description:
This patch is to create directory '/sys/firmware/acpi/memory/',
directories for each ACPI memory object, and files under it.  These
files are to export information of ACPI memory object.  This version
just creates two files an ACPI memory object, min_address_range and
max_address_range.  What it looks like is:
/sys/firmware/acpi/memory/MEM0/min_address_range, where MEM0 is an
ACPI memory object name.


---

 drivers/acpi/memory.c |  199 ++++++++++++++++++++++++++++++++++++++++++++++++--
 1 files changed, 194 insertions(+), 5 deletions(-)

diff -puN drivers/acpi/memory.c~sysfs_memory drivers/acpi/memory.c
--- linux-2.6.8.1-mm3/drivers/acpi/memory.c~sysfs_memory	2004-09-16 10:19:00.000000000 +0900
+++ linux-2.6.8.1-mm3-kei/drivers/acpi/memory.c	2004-09-24 17:31:13.000000000 +0900
@@ -69,6 +69,15 @@ static struct acpi_driver acpi_memory_de
 			},
 };
 
+struct acpi_mem {
+	struct acpi_mem_device_ops	*ops;
+	void (*release)(struct acpi_mem *mdev);
+	struct kobject			kobj;
+};
+
+#define to_acpi_mem(n) container_of(n, struct acpi_mem, kobj)
+#define acpi_mem_to_dev(n) container_of(n, struct acpi_memory_device, amem)
+
 struct acpi_memory_device {
 	acpi_handle handle;	
 	unsigned int state;		/* State of the memory device */
@@ -76,8 +85,171 @@ struct acpi_memory_device {
 	unsigned short read_write_attribute;/* memory read/write attribute */
 	u64 start_addr;	/* Memory Range start physical addr */
 	u64 end_addr;	/* Memory Range end physical addr */
+	struct acpi_resource resource;
+	struct acpi_mem amem;
+};
+
+/*
+ * /sys/firmware/acpi/memory/
+ */
+struct acpi_mem_attribute {
+	struct attribute attr;
+	ssize_t (*show)(struct acpi_mem *, char *);
+	ssize_t (*store)(struct acpi_mem *, const char *, size_t);
+};
+
+#define to_acpi_mem_attr(n) container_of(n, struct acpi_mem_attribute, attr)
+
+static ssize_t acpi_mem_attr_show(struct kobject *kobj,
+				  struct attribute *attr, char *buf)
+{
+	struct acpi_mem *amem = to_acpi_mem(kobj);
+	struct acpi_mem_attribute *attribute = to_acpi_mem_attr(attr);
+	return attribute->show ? attribute->show(amem, buf) : 0;
+}
+
+static ssize_t acpi_mem_attr_store(struct kobject *kobj,
+				   struct attribute *attr, const char *buf,
+				   size_t len)
+{
+	struct acpi_mem *amem = to_acpi_mem(kobj);
+	struct acpi_mem_attribute *attribute = to_acpi_mem_attr(attr);
+	return attribute->store ? attribute->store(amem, buf, len) : 0;
+}
+
+static struct sysfs_ops acpi_mem_sysfs_ops = {
+	.show = acpi_mem_attr_show,
+	.store = acpi_mem_attr_store,
+};
+
+static void acpi_mem_release(struct kobject *kobj)
+{
+	sysfs_remove_dir(kobj);
+	if (kobj->kset) {
+		down_write(&kobj->kset->subsys->rwsem);
+		list_del_init(&kobj->entry);
+		up_write(&kobj->kset->subsys->rwsem);
+	}
+}
+
+static struct kobj_type acpi_mem_ktype = {
+	.sysfs_ops = &acpi_mem_sysfs_ops,
+	.release = &acpi_mem_release,
 };
 
+static decl_subsys_name(acpi_mem, memory, &acpi_mem_ktype, NULL);
+
+static int acpi_mem_register(struct acpi_mem *amem)
+{
+	return kobject_register(&amem->kobj);
+}
+
+int create_acpi_mem(struct acpi_memory_device *mem_device,
+			   struct acpi_device *device)
+{
+	int result;
+	struct acpi_mem *amem = &mem_device->amem;
+
+	ACPI_FUNCTION_TRACE("create_acpi_mem");
+
+	memset(amem, 0, sizeof(struct acpi_mem));
+	kobject_set_name(&amem->kobj, device->pnp.bus_id);
+	kobj_set_kset_s(amem, acpi_mem_subsys);
+	amem->kobj.parent = &acpi_mem_subsys.kset.kobj;
+
+	result = acpi_mem_register(amem);
+	if (result)
+		goto end;
+end:
+	return_VALUE(result);
+}
+
+int acpi_mem_fs_init(void)
+{
+	int result;
+	extern struct subsystem acpi_subsys;
+
+	ACPI_FUNCTION_TRACE("acpi_mem_fs_init");
+
+	acpi_mem_subsys.kset.kobj.parent = &acpi_subsys.kset.kobj;
+	result = subsystem_register(&acpi_mem_subsys);
+
+	return_VALUE(result);
+}
+
+void acpi_mem_fs_exit(void)
+{
+	ACPI_FUNCTION_TRACE("acpi_mem_fs_exit");
+
+	subsystem_unregister(&acpi_mem_subsys);
+
+	return_VOID;
+}
+
+static int get_address64(struct acpi_mem *amem,
+			 struct acpi_resource_address64 *address64)
+{
+	struct acpi_memory_device	*mem_device = acpi_mem_to_dev(amem);
+	struct acpi_resource		*resource;
+
+	if (!mem_device)
+		return -ENODEV;
+
+	resource = &mem_device->resource;
+
+	acpi_resource_to_address64(resource, address64);
+
+	if (address64->resource_type != ACPI_MEMORY_RANGE)
+		return -EINVAL;
+
+	return 0;
+}
+
+static ssize_t min_address_range_read_file(struct acpi_mem *amem, char *buf)
+{
+	int result;
+	struct acpi_resource_address64 address64;
+
+	result = get_address64(amem, &address64);
+	if (result)
+		return result;
+
+	result = sprintf(buf, "0x%llx\n", address64.min_address_range);
+
+	return result;
+}
+
+static struct acpi_mem_attribute acpi_mem_attr_min_address_range = {
+	.attr = {.name = "min_address_range", .mode = S_IFREG | S_IRUGO},
+	.show = min_address_range_read_file,
+};
+
+static ssize_t max_address_range_read_file(struct acpi_mem *amem, char *buf)
+{
+	int result;
+	struct acpi_resource_address64 address64;
+
+	result = get_address64(amem, &address64);
+	if (result)
+		return result;
+
+	result = sprintf(buf, "0x%llx\n", address64.max_address_range);
+
+	return result;
+}
+
+static struct acpi_mem_attribute acpi_mem_attr_max_address_range = {
+	.attr = {.name = "max_address_range", .mode = S_IFREG | S_IRUGO},
+	.show = max_address_range_read_file,
+};
+
+static int fs_add_memory(struct acpi_mem *amem)
+{
+	sysfs_create_file(&amem->kobj, &acpi_mem_attr_min_address_range.attr);
+	sysfs_create_file(&amem->kobj, &acpi_mem_attr_max_address_range.attr);
+
+	return 0;
+}
 
 static int 
 acpi_memory_get_device_resources(struct acpi_memory_device *mem_device) 
@@ -97,6 +269,7 @@ acpi_memory_get_device_resources(struct 
 		return_VALUE(-EINVAL);
 
 	resource = (struct acpi_resource *) buffer.pointer;
+	mem_device->resource = *resource;
 		
 	switch (resource->id) {
 	case ACPI_RSTYPE_ADDRESS16:
@@ -413,17 +586,26 @@ acpi_memory_device_add(struct acpi_devic
 
 	/* Get the range from the _CRS */
 	result = acpi_memory_get_device_resources(mem_device);
-	if (result) {
-		kfree(mem_device);
-		return_VALUE(result);
-	}
-		
+	if (result)
+		goto errout;
+
+	result = create_acpi_mem(mem_device, device);
+	if (result)
+		goto errout;
+
+	result = fs_add_memory(&mem_device->amem);
+	if (result)
+		goto errout;
+
 	/* Set the device state */
 	mem_device->state = MEMORY_POWER_ON_STATE;
 
 	printk(KERN_INFO "%s \n", acpi_device_name(device));
 
 	return_VALUE(result);
+errout:
+	kfree(mem_device);
+	return_VALUE(result);
 }
 
 static int 
@@ -527,6 +709,10 @@ acpi_memory_device_init (void)
 
 	ACPI_FUNCTION_TRACE("acpi_memory_device_init");
 
+	result = acpi_mem_fs_init();
+	if (result)
+		return_VALUE(-ENODEV);
+
 	result = acpi_bus_register_driver(&acpi_memory_device_driver);
 
 	if (result < 0) 
@@ -540,6 +726,7 @@ acpi_memory_device_init (void)
 	if (ACPI_FAILURE (status)) {
 		ACPI_DEBUG_PRINT ((ACPI_DB_ERROR, "walk_namespace failed\n"));
 		acpi_bus_unregister_driver(&acpi_memory_device_driver);
+		acpi_mem_fs_exit();
 		return_VALUE(-ENODEV);
         }
 
@@ -567,6 +754,8 @@ acpi_memory_device_exit (void)
 
 	acpi_bus_unregister_driver(&acpi_memory_device_driver);
 
+	acpi_mem_fs_exit();
+
 	return_VOID;
 }
 

_


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php