[PATCH v2 0/3] acpi,memory-hotplug : implement framework for hot removing memory

[PATCH v2 0/3] acpi,memory-hotplug : implement framework for hot removing memory

[wency]

From: Wen Congyang <wency@cn.fujitsu.com>

The patch-set implements a framework for hot removing memory.

The memory device can be removed by 2 ways:
1. send eject request by SCI
2. echo 1 >/sys/bus/pci/devices/PNP0C80:XX/eject

In the 1st case, acpi_memory_disable_device() will be called.
In the 2nd case, acpi_memory_device_remove() will be called.
acpi_memory_device_remove() will also be called when we unbind the
memory device from the driver acpi_memhotplug or a driver initialization
fails.

acpi_memory_disable_device() has already implemented a code which
offlines memory and releases acpi_memory_info struct . But
acpi_memory_device_remove() has not implemented it yet.

So the patch prepares the framework for hot removing memory and
adds the framework into acpi_memory_device_remove().

The last version of this patchset is here:
https://lkml.org/lkml/2012/10/3/126

Changelos from v1 to v2:
  Patch1: use acpi_bus_trim() instead of acpi_bus_remove()
  Patch2: new patch, introduce a lock to protect the list
  Patch3: remove memory too when type is ACPI_BUS_REMOVAL_NORMAL
  Note: I don't send [Patch2-4 v1] in this series because they
  are no logical changes in these 3 patches.

Wen Congyang (2):
  acpi,memory-hotplug: call acpi_bus_trim() to remove memory device
  acpi,memory-hotplug: introduce a mutex lock to protect the list in
    acpi_memory_device

Yasuaki Ishimatsu (1):
  acpi,memory-hotplug : add memory offline code to
    acpi_memory_device_remove()

 drivers/acpi/acpi_memhotplug.c |   51 ++++++++++++++++++++++++++++++++--------
 1 files changed, 41 insertions(+), 10 deletions(-)

[PATCH v2 1/3] acpi,memory-hotplug: call acpi_bus_trim() to remove memory device

[wency]

From: Wen Congyang <wency@cn.fujitsu.com>

The memory device has been ejected and powoffed, so we can call
acpi_bus_trim() to remove the memory device from acpi bus.

CC: David Rientjes <rientjes@google.com>
CC: Jiang Liu <liuj97@gmail.com>
CC: Len Brown <len.brown@intel.com>
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: Paul Mackerras <paulus@samba.org>
CC: Christoph Lameter <cl@linux.com>
Cc: Minchan Kim <minchan.kim@gmail.com>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
CC: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
---
 drivers/acpi/acpi_memhotplug.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
index 24c807f..1e90e8f 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -401,8 +401,9 @@ static void acpi_memory_device_notify(acpi_handle handle, u32 event, void *data)
 		}
 
 		/*
-		 * TBD: Invoke acpi_bus_remove to cleanup data structures
+		 * Invoke acpi_bus_trim() to remove memory device
 		 */
+		acpi_bus_trim(device, 1);
 
 		/* _EJ0 succeeded; _OST is not necessary */
 		return;
-- 
1.7.1

[PATCH v2 2/3] acpi,memory-hotplug: introduce a mutex lock to protect the list in acpi_memory_device

[wency]

From: Wen Congyang <wency@cn.fujitsu.com>

The memory device can be removed by 2 ways:
1. send eject request by SCI
2. echo 1 >/sys/bus/pci/devices/PNP0C80:XX/eject

This 2 events may happen at the same time, so we may touch
acpi_memory_device.res_list at the same time. This patch
introduce a lock to protect this list.

CC: David Rientjes <rientjes@google.com>
CC: Jiang Liu <liuj97@gmail.com>
CC: Len Brown <len.brown@intel.com>
CC: Christoph Lameter <cl@linux.com>
Cc: Minchan Kim <minchan.kim@gmail.com>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
CC: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
---
 drivers/acpi/acpi_memhotplug.c |   17 +++++++++++++++--
 1 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
index 1e90e8f..8ff2976 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -83,7 +83,8 @@ struct acpi_memory_info {
 struct acpi_memory_device {
 	struct acpi_device * device;
 	unsigned int state;	/* State of the memory device */
-	struct list_head res_list;
+	struct mutex lock;
+	struct list_head res_list;	/* protected by lock */
 };
 
 static int acpi_hotmem_initialized;
@@ -101,19 +102,23 @@ acpi_memory_get_resource(struct acpi_resource *resource, void *context)
 	    (address64.resource_type != ACPI_MEMORY_RANGE))
 		return AE_OK;
 
+	mutex_lock(&mem_device->lock);
 	list_for_each_entry(info, &mem_device->res_list, list) {
 		/* Can we combine the resource range information? */
 		if ((info->caching == address64.info.mem.caching) &&
 		    (info->write_protect == address64.info.mem.write_protect) &&
 		    (info->start_addr + info->length == address64.minimum)) {
 			info->length += address64.address_length;
+			mutex_unlock(&mem_device->lock);
 			return AE_OK;
 		}
 	}
 
 	new = kzalloc(sizeof(struct acpi_memory_info), GFP_KERNEL);
-	if (!new)
+	if (!new) {
+		mutex_unlock(&mem_device->lock);
 		return AE_ERROR;
+	}
 
 	INIT_LIST_HEAD(&new->list);
 	new->caching = address64.info.mem.caching;
@@ -121,6 +126,7 @@ acpi_memory_get_resource(struct acpi_resource *resource, void *context)
 	new->start_addr = address64.minimum;
 	new->length = address64.address_length;
 	list_add_tail(&new->list, &mem_device->res_list);
+	mutex_unlock(&mem_device->lock);
 
 	return AE_OK;
 }
@@ -138,9 +144,11 @@ acpi_memory_get_device_resources(struct acpi_memory_device *mem_device)
 	status = acpi_walk_resources(mem_device->device->handle, METHOD_NAME__CRS,
 				     acpi_memory_get_resource, mem_device);
 	if (ACPI_FAILURE(status)) {
+		mutex_lock(&mem_device->lock);
 		list_for_each_entry_safe(info, n, &mem_device->res_list, list)
 			kfree(info);
 		INIT_LIST_HEAD(&mem_device->res_list);
+		mutex_unlock(&mem_device->lock);
 		return -EINVAL;
 	}
 
@@ -236,6 +244,7 @@ static int acpi_memory_enable_device(struct acpi_memory_device *mem_device)
 	 * We don't have memory-hot-add rollback function,now.
 	 * (i.e. memory-hot-remove function)
 	 */
+	mutex_lock(&mem_device->lock);
 	list_for_each_entry(info, &mem_device->res_list, list) {
 		if (info->enabled) { /* just sanity check...*/
 			num_enabled++;
@@ -256,6 +265,7 @@ static int acpi_memory_enable_device(struct acpi_memory_device *mem_device)
 		info->enabled = 1;
 		num_enabled++;
 	}
+	mutex_unlock(&mem_device->lock);
 	if (!num_enabled) {
 		printk(KERN_ERR PREFIX "add_memory failed\n");
 		mem_device->state = MEMORY_INVALID_STATE;
@@ -316,6 +326,7 @@ static int acpi_memory_disable_device(struct acpi_memory_device *mem_device)
 	 * Ask the VM to offline this memory range.
 	 * Note: Assume that this function returns zero on success
 	 */
+	mutex_lock(&mem_device->lock);
 	list_for_each_entry_safe(info, n, &mem_device->res_list, list) {
 		if (info->enabled) {
 			result = remove_memory(info->start_addr, info->length);
@@ -324,6 +335,7 @@ static int acpi_memory_disable_device(struct acpi_memory_device *mem_device)
 		}
 		kfree(info);
 	}
+	mutex_unlock(&mem_device->lock);
 
 	/* Power-off and eject the device */
 	result = acpi_memory_powerdown_device(mem_device);
@@ -438,6 +450,7 @@ static int acpi_memory_device_add(struct acpi_device *device)
 	mem_device->device = device;
 	sprintf(acpi_device_name(device), "%s", ACPI_MEMORY_DEVICE_NAME);
 	sprintf(acpi_device_class(device), "%s", ACPI_MEMORY_DEVICE_CLASS);
+	mutex_init(&mem_device->lock);
 	device->driver_data = mem_device;
 
 	/* Get the range from the _CRS */
-- 
1.7.1

[PATCH v2 3/3] acpi,memory-hotplug : add memory offline code to acpi_memory_device_remove()

[wency]

From: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>

The memory device can be removed by 2 ways:
1. send eject request by SCI
2. echo 1 >/sys/bus/pci/devices/PNP0C80:XX/eject

In the 1st case, acpi_memory_disable_device() will be called.
In the 2nd case, acpi_memory_device_remove() will be called.
acpi_memory_device_remove() will also be called when we unbind the
memory device from the driver acpi_memhotplug or a driver initialization
fails.

acpi_memory_disable_device() has already implemented a code which
offlines memory and releases acpi_memory_info struct. But
acpi_memory_device_remove() has not implemented it yet.

So the patch move offlining memory and releasing acpi_memory_info struct
codes to a new function acpi_memory_remove_memory(). And it is used by both
acpi_memory_device_remove() and acpi_memory_disable_device().

CC: David Rientjes <rientjes@google.com>
CC: Jiang Liu <liuj97@gmail.com>
CC: Len Brown <len.brown@intel.com>
CC: Christoph Lameter <cl@linux.com>
Cc: Minchan Kim <minchan.kim@gmail.com>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
---
 drivers/acpi/acpi_memhotplug.c |   31 ++++++++++++++++++++++++-------
 1 files changed, 24 insertions(+), 7 deletions(-)

diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
index 8ff2976..5b28aa9 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -316,16 +316,11 @@ static int acpi_memory_powerdown_device(struct acpi_memory_device *mem_device)
 	return 0;
 }
 
-static int acpi_memory_disable_device(struct acpi_memory_device *mem_device)
+static int acpi_memory_remove_memory(struct acpi_memory_device *mem_device)
 {
 	int result;
 	struct acpi_memory_info *info, *n;
 
-
-	/*
-	 * Ask the VM to offline this memory range.
-	 * Note: Assume that this function returns zero on success
-	 */
 	mutex_lock(&mem_device->lock);
 	list_for_each_entry_safe(info, n, &mem_device->res_list, list) {
 		if (info->enabled) {
@@ -333,10 +328,27 @@ static int acpi_memory_disable_device(struct acpi_memory_device *mem_device)
 			if (result)
 				return result;
 		}
+
+		list_del(&info->list);
 		kfree(info);
 	}
 	mutex_unlock(&mem_device->lock);
 
+	return 0;
+}
+
+static int acpi_memory_disable_device(struct acpi_memory_device *mem_device)
+{
+	int result;
+
+	/*
+	 * Ask the VM to offline this memory range.
+	 * Note: Assume that this function returns zero on success
+	 */
+	result = acpi_memory_remove_memory(mem_device);
+	if (result)
+		return result;
+
 	/* Power-off and eject the device */
 	result = acpi_memory_powerdown_device(mem_device);
 	if (result) {
@@ -487,12 +499,17 @@ static int acpi_memory_device_add(struct acpi_device *device)
 static int acpi_memory_device_remove(struct acpi_device *device, int type)
 {
 	struct acpi_memory_device *mem_device = NULL;
-
+	int result;
 
 	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;
+
 	kfree(mem_device);
 
 	return 0;
-- 
1.7.1

Re: [PATCH v2 0/3] acpi,memory-hotplug : implement framework for hot removing memory

[Yasuaki Ishimatsu]

CCing Rafael, because he become ACPI Maintainer.

Hi Wen,

If you update the patch-set, please CCing Rafael from the next time.

Thanks,
Yasuaki Ishimatsu

2012/10/19 19:03, wency@cn.fujitsu.com wrote:
> From: Wen Congyang <wency@cn.fujitsu.com>
> 
> The patch-set implements a framework for hot removing memory.
> 
> The memory device can be removed by 2 ways:
> 1. send eject request by SCI
> 2. echo 1 >/sys/bus/pci/devices/PNP0C80:XX/eject
> 
> In the 1st case, acpi_memory_disable_device() will be called.
> In the 2nd case, acpi_memory_device_remove() will be called.
> acpi_memory_device_remove() will also be called when we unbind the
> memory device from the driver acpi_memhotplug or a driver initialization
> fails.
> 
> acpi_memory_disable_device() has already implemented a code which
> offlines memory and releases acpi_memory_info struct . But
> acpi_memory_device_remove() has not implemented it yet.
> 
> So the patch prepares the framework for hot removing memory and
> adds the framework into acpi_memory_device_remove().
> 
> The last version of this patchset is here:
> https://lkml.org/lkml/2012/10/3/126
> 
> Changelos from v1 to v2:
>    Patch1: use acpi_bus_trim() instead of acpi_bus_remove()
>    Patch2: new patch, introduce a lock to protect the list
>    Patch3: remove memory too when type is ACPI_BUS_REMOVAL_NORMAL
>    Note: I don't send [Patch2-4 v1] in this series because they
>    are no logical changes in these 3 patches.
> 
> Wen Congyang (2):
>    acpi,memory-hotplug: call acpi_bus_trim() to remove memory device
>    acpi,memory-hotplug: introduce a mutex lock to protect the list in
>      acpi_memory_device
> 
> Yasuaki Ishimatsu (1):
>    acpi,memory-hotplug : add memory offline code to
>      acpi_memory_device_remove()
> 
>   drivers/acpi/acpi_memhotplug.c |   51 ++++++++++++++++++++++++++++++++--------
>   1 files changed, 41 insertions(+), 10 deletions(-)
> 

Re: [PATCH v2 0/3] acpi,memory-hotplug : implement framework for hot removing memory

[Wen Congyang]

At 10/19/2012 06:19 PM, Yasuaki Ishimatsu Wrote:
> CCing Rafael, because he become ACPI Maintainer.
> 
> Hi Wen,
> 
> If you update the patch-set, please CCing Rafael from the next time.

OK.

Thanks
Wen Congyang

> 
> Thanks,
> Yasuaki Ishimatsu
> 
> 2012/10/19 19:03, wency@cn.fujitsu.com wrote:
>> From: Wen Congyang <wency@cn.fujitsu.com>
>>
>> The patch-set implements a framework for hot removing memory.
>>
>> The memory device can be removed by 2 ways:
>> 1. send eject request by SCI
>> 2. echo 1 >/sys/bus/pci/devices/PNP0C80:XX/eject
>>
>> In the 1st case, acpi_memory_disable_device() will be called.
>> In the 2nd case, acpi_memory_device_remove() will be called.
>> acpi_memory_device_remove() will also be called when we unbind the
>> memory device from the driver acpi_memhotplug or a driver initialization
>> fails.
>>
>> acpi_memory_disable_device() has already implemented a code which
>> offlines memory and releases acpi_memory_info struct . But
>> acpi_memory_device_remove() has not implemented it yet.
>>
>> So the patch prepares the framework for hot removing memory and
>> adds the framework into acpi_memory_device_remove().
>>
>> The last version of this patchset is here:
>> https://lkml.org/lkml/2012/10/3/126
>>
>> Changelos from v1 to v2:
>>    Patch1: use acpi_bus_trim() instead of acpi_bus_remove()
>>    Patch2: new patch, introduce a lock to protect the list
>>    Patch3: remove memory too when type is ACPI_BUS_REMOVAL_NORMAL
>>    Note: I don't send [Patch2-4 v1] in this series because they
>>    are no logical changes in these 3 patches.
>>
>> Wen Congyang (2):
>>    acpi,memory-hotplug: call acpi_bus_trim() to remove memory device
>>    acpi,memory-hotplug: introduce a mutex lock to protect the list in
>>      acpi_memory_device
>>
>> Yasuaki Ishimatsu (1):
>>    acpi,memory-hotplug : add memory offline code to
>>      acpi_memory_device_remove()
>>
>>   drivers/acpi/acpi_memhotplug.c |   51 ++++++++++++++++++++++++++++++++--------
>>   1 files changed, 41 insertions(+), 10 deletions(-)
>>
> 
> 
> 

Re: [PATCH v2 0/3] acpi,memory-hotplug : implement framework for hot removing memory

[Rafael J. Wysocki]

On Friday 19 of October 2012 18:03:57 wency@cn.fujitsu.com wrote:
> From: Wen Congyang <wency@cn.fujitsu.com>
> 
> The patch-set implements a framework for hot removing memory.
> 
> The memory device can be removed by 2 ways:
> 1. send eject request by SCI
> 2. echo 1 >/sys/bus/pci/devices/PNP0C80:XX/eject
> 
> In the 1st case, acpi_memory_disable_device() will be called.
> In the 2nd case, acpi_memory_device_remove() will be called.
> acpi_memory_device_remove() will also be called when we unbind the
> memory device from the driver acpi_memhotplug or a driver initialization
> fails.
> 
> acpi_memory_disable_device() has already implemented a code which
> offlines memory and releases acpi_memory_info struct . But
> acpi_memory_device_remove() has not implemented it yet.
> 
> So the patch prepares the framework for hot removing memory and
> adds the framework into acpi_memory_device_remove().
> 
> The last version of this patchset is here:
> https://lkml.org/lkml/2012/10/3/126
> 
> Changelos from v1 to v2:
>   Patch1: use acpi_bus_trim() instead of acpi_bus_remove()
>   Patch2: new patch, introduce a lock to protect the list
>   Patch3: remove memory too when type is ACPI_BUS_REMOVAL_NORMAL
>   Note: I don't send [Patch2-4 v1] in this series because they
>   are no logical changes in these 3 patches.
> 
> Wen Congyang (2):
>   acpi,memory-hotplug: call acpi_bus_trim() to remove memory device
>   acpi,memory-hotplug: introduce a mutex lock to protect the list in
>     acpi_memory_device
> 
> Yasuaki Ishimatsu (1):
>   acpi,memory-hotplug : add memory offline code to
>     acpi_memory_device_remove()
> 
>  drivers/acpi/acpi_memhotplug.c |   51 ++++++++++++++++++++++++++++++++--------
>  1 files changed, 41 insertions(+), 10 deletions(-)
> 
> --

Can you please tell me what kernel is the series supposed to apply to?
Is it the current Linus' tree, or linux-next, or something else?

Thanks,
Rafael


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

Re: [PATCH v2 1/3] acpi,memory-hotplug: call acpi_bus_trim() to remove memory device

[KOSAKI Motohiro]

On Fri, Oct 19, 2012 at 6:03 AM,  <wency@cn.fujitsu.com> wrote:
> From: Wen Congyang <wency@cn.fujitsu.com>
>
> The memory device has been ejected and powoffed, so we can call
> acpi_bus_trim() to remove the memory device from acpi bus.
>
> CC: David Rientjes <rientjes@google.com>
> CC: Jiang Liu <liuj97@gmail.com>
> CC: Len Brown <len.brown@intel.com>
> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> CC: Paul Mackerras <paulus@samba.org>
> CC: Christoph Lameter <cl@linux.com>
> Cc: Minchan Kim <minchan.kim@gmail.com>
> CC: Andrew Morton <akpm@linux-foundation.org>
> CC: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> CC: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
> ---
>  drivers/acpi/acpi_memhotplug.c |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
> index 24c807f..1e90e8f 100644
> --- a/drivers/acpi/acpi_memhotplug.c
> +++ b/drivers/acpi/acpi_memhotplug.c
> @@ -401,8 +401,9 @@ static void acpi_memory_device_notify(acpi_handle handle, u32 event, void *data)
>                 }
>
>                 /*
> -                * TBD: Invoke acpi_bus_remove to cleanup data structures
> +                * Invoke acpi_bus_trim() to remove memory device
>                  */
> +               acpi_bus_trim(device, 1);

I'm happy we removed mysterious acpi_bus_remove().

Re: [PATCH v2 2/3] acpi,memory-hotplug: introduce a mutex lock to protect the list in acpi_memory_device

[KOSAKI Motohiro]

On Fri, Oct 19, 2012 at 6:03 AM,  <wency@cn.fujitsu.com> wrote:
> From: Wen Congyang <wency@cn.fujitsu.com>
>
> The memory device can be removed by 2 ways:
> 1. send eject request by SCI
> 2. echo 1 >/sys/bus/pci/devices/PNP0C80:XX/eject
>
> This 2 events may happen at the same time, so we may touch
> acpi_memory_device.res_list at the same time. This patch
> introduce a lock to protect this list.
>
> CC: David Rientjes <rientjes@google.com>
> CC: Jiang Liu <liuj97@gmail.com>
> CC: Len Brown <len.brown@intel.com>
> CC: Christoph Lameter <cl@linux.com>
> Cc: Minchan Kim <minchan.kim@gmail.com>
> CC: Andrew Morton <akpm@linux-foundation.org>
> CC: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> CC: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
> ---
>  drivers/acpi/acpi_memhotplug.c |   17 +++++++++++++++--
>  1 files changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
> index 1e90e8f..8ff2976 100644
> --- a/drivers/acpi/acpi_memhotplug.c
> +++ b/drivers/acpi/acpi_memhotplug.c
> @@ -83,7 +83,8 @@ struct acpi_memory_info {
>  struct acpi_memory_device {
>         struct acpi_device * device;
>         unsigned int state;     /* State of the memory device */
> -       struct list_head res_list;
> +       struct mutex lock;
> +       struct list_head res_list;      /* protected by lock */
>  };

Please avoid grep unfriendly name. "lock" is too common. res_list_lock
or list_lock
are better IMHO.

Re: [PATCH v2 0/3] acpi,memory-hotplug : implement framework for hot removing memory

[Wen Congyang]

At 10/20/2012 12:32 AM, Rafael J. Wysocki Wrote:
> On Friday 19 of October 2012 18:03:57 wency@cn.fujitsu.com wrote:
>> From: Wen Congyang <wency@cn.fujitsu.com>
>>
>> The patch-set implements a framework for hot removing memory.
>>
>> The memory device can be removed by 2 ways:
>> 1. send eject request by SCI
>> 2. echo 1 >/sys/bus/pci/devices/PNP0C80:XX/eject
>>
>> In the 1st case, acpi_memory_disable_device() will be called.
>> In the 2nd case, acpi_memory_device_remove() will be called.
>> acpi_memory_device_remove() will also be called when we unbind the
>> memory device from the driver acpi_memhotplug or a driver initialization
>> fails.
>>
>> acpi_memory_disable_device() has already implemented a code which
>> offlines memory and releases acpi_memory_info struct . But
>> acpi_memory_device_remove() has not implemented it yet.
>>
>> So the patch prepares the framework for hot removing memory and
>> adds the framework into acpi_memory_device_remove().
>>
>> The last version of this patchset is here:
>> https://lkml.org/lkml/2012/10/3/126
>>
>> Changelos from v1 to v2:
>>   Patch1: use acpi_bus_trim() instead of acpi_bus_remove()
>>   Patch2: new patch, introduce a lock to protect the list
>>   Patch3: remove memory too when type is ACPI_BUS_REMOVAL_NORMAL
>>   Note: I don't send [Patch2-4 v1] in this series because they
>>   are no logical changes in these 3 patches.
>>
>> Wen Congyang (2):
>>   acpi,memory-hotplug: call acpi_bus_trim() to remove memory device
>>   acpi,memory-hotplug: introduce a mutex lock to protect the list in
>>     acpi_memory_device
>>
>> Yasuaki Ishimatsu (1):
>>   acpi,memory-hotplug : add memory offline code to
>>     acpi_memory_device_remove()
>>
>>  drivers/acpi/acpi_memhotplug.c |   51 ++++++++++++++++++++++++++++++++--------
>>  1 files changed, 41 insertions(+), 10 deletions(-)
>>
>> --
> 
> Can you please tell me what kernel is the series supposed to apply to?
> Is it the current Linus' tree, or linux-next, or something else?

Current Linux's tree.

Thanks
Wen Congyang

> 
> Thanks,
> Rafael
> 
>