All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiang Liu <jiang.liu@huawei.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Cc: Wen Congyang <wency@cn.fujitsu.com>,
	"Rafael J. Wysocki" <rjw@sisk.pl>, Toshi Kani <toshi.kani@hp.com>,
	"Wysocki, Rafael J" <rafael.j.wysocki@intel.com>,
	"lenb@kernel.org" <lenb@kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [PATCH] X86/acpi: remove redundant logic of acpi memory hotadd
Date: Thu, 13 Dec 2012 10:36:38 +0800	[thread overview]
Message-ID: <50C93F36.4030402@huawei.com> (raw)
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923353A779A@SHSMSX101.ccr.corp.intel.com>

On 2012-12-12 22:37, Liu, Jinsong wrote:
> Wen Congyang wrote:
>> At 12/08/2012 06:19 AM, Rafael J. Wysocki Wrote:
>>> On Tuesday, December 04, 2012 01:39:54 AM Liu, Jinsong wrote:
>>>> Resend it, add Rafael and linux-acpi@vger.kernel.org
>>>
>>> I wonder what memory hotplug people think about that.
>>>
>>> Thanks,
>>> Rafael
>>>
>>>
>>>> ===============
>>>> From 1d39279e45c54ce531691da5ffe261e7689dd92c Mon Sep 17 00:00:00
>>>> 2001 
>>>> From: Liu Jinsong <jinsong.liu@intel.com>
>>>> Date: Wed, 14 Nov 2012 18:52:06 +0800
>>>> Subject: [PATCH] X86/acpi: remove redundant logic of acpi memory
>>>> hotadd 
>>>>
>>>> When memory hotadd, acpi_memory_enable_device has already been done
>>>> at drv->ops.add (acpi_memory_device_add), no need to do it again
>>>> at notify callback.
>>>>
>>>> At acpi_memory_enable_device, acpi_memory_get_device_resources
>>>> is also a redundant action, since it has been done at drv->ops.add.
>>>>
>>>> Signed-off-by: Liu Jinsong <jinsong.liu@intel.com>
>>>> ---
>>>>  drivers/acpi/acpi_memhotplug.c |   17 -----------------
>>>>  1 files changed, 0 insertions(+), 17 deletions(-)
>>>>
>>>> diff --git a/drivers/acpi/acpi_memhotplug.c
>>>> b/drivers/acpi/acpi_memhotplug.c 
>>>> index 24c807f..a6489fd 100644
>>>> --- a/drivers/acpi/acpi_memhotplug.c
>>>> +++ b/drivers/acpi/acpi_memhotplug.c
>>>> @@ -220,15 +220,6 @@ static int acpi_memory_enable_device(struct
>>>>  	acpi_memory_device *mem_device) struct acpi_memory_info *info;
>>>>  	int node;
>>>>
>>>> -
>>>> -	/* Get the range from the _CRS */
>>>> -	result = acpi_memory_get_device_resources(mem_device);
>>>> -	if (result) {
>>>> -		printk(KERN_ERR PREFIX "get_device_resources failed\n");
>>>> -		mem_device->state = MEMORY_INVALID_STATE;
>>>> -		return result;
>>>> -	}
>>>> -
>>>>  	node = acpi_get_node(mem_device->device->handle);  	/*
>>>>  	 * Tell the VM there is more memory here...
>>>> @@ -357,14 +348,6 @@ static void
>>>>  		acpi_memory_device_notify(acpi_handle handle, u32 event, void
>>>> *data)  			break; } 
>>>>
>>>> -		if (acpi_memory_check_device(mem_device))
>>>> -			break;
>>
>> Hmm, if acpi_memory_check_device() fails, it means the memory device
>> disappears 
>> I don't know if a real hardware uses this way to remove memory device.
>>
>>>> -
>>>> -		if (acpi_memory_enable_device(mem_device)) {
>>>> -			printk(KERN_ERR PREFIX "Cannot enable memory device\n");
>>>> -			break;
>>>> -		}
>>
>> If acpi_memory_get_device() doesn't fail, it means that the device
>> has been managed by this driver, so I think we can do this cleanup.
>>
>> Thanks
>> Wen Congyang
>>
> 
> Thanks! any comments from Huawei side, Jiang?
Hi Jinsong,

We think it's ok.

acpi_memory_device_notify
	acpi_memory_get_device
		acpi_memory_device_add
			acpi_memory_get_device_resources
			acpi_memory_enable_device
				acpi_memory_get_device_resources(redundant)
	acpi_memory_check_device(redundant)
	acpi_memory_enable_device(redundant)

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Jiang Liu <jiang.liu@huawei.com>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Cc: Wen Congyang <wency@cn.fujitsu.com>,
	"Rafael J. Wysocki" <rjw@sisk.pl>, Toshi Kani <toshi.kani@hp.com>,
	"Wysocki, Rafael J" <rafael.j.wysocki@intel.com>,
	"lenb@kernel.org" <lenb@kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [PATCH] X86/acpi: remove redundant logic of acpi memory hotadd
Date: Thu, 13 Dec 2012 10:36:38 +0800	[thread overview]
Message-ID: <50C93F36.4030402@huawei.com> (raw)
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923353A779A@SHSMSX101.ccr.corp.intel.com>

On 2012-12-12 22:37, Liu, Jinsong wrote:
> Wen Congyang wrote:
>> At 12/08/2012 06:19 AM, Rafael J. Wysocki Wrote:
>>> On Tuesday, December 04, 2012 01:39:54 AM Liu, Jinsong wrote:
>>>> Resend it, add Rafael and linux-acpi@vger.kernel.org
>>>
>>> I wonder what memory hotplug people think about that.
>>>
>>> Thanks,
>>> Rafael
>>>
>>>
>>>> ===============
>>>> From 1d39279e45c54ce531691da5ffe261e7689dd92c Mon Sep 17 00:00:00
>>>> 2001 
>>>> From: Liu Jinsong <jinsong.liu@intel.com>
>>>> Date: Wed, 14 Nov 2012 18:52:06 +0800
>>>> Subject: [PATCH] X86/acpi: remove redundant logic of acpi memory
>>>> hotadd 
>>>>
>>>> When memory hotadd, acpi_memory_enable_device has already been done
>>>> at drv->ops.add (acpi_memory_device_add), no need to do it again
>>>> at notify callback.
>>>>
>>>> At acpi_memory_enable_device, acpi_memory_get_device_resources
>>>> is also a redundant action, since it has been done at drv->ops.add.
>>>>
>>>> Signed-off-by: Liu Jinsong <jinsong.liu@intel.com>
>>>> ---
>>>>  drivers/acpi/acpi_memhotplug.c |   17 -----------------
>>>>  1 files changed, 0 insertions(+), 17 deletions(-)
>>>>
>>>> diff --git a/drivers/acpi/acpi_memhotplug.c
>>>> b/drivers/acpi/acpi_memhotplug.c 
>>>> index 24c807f..a6489fd 100644
>>>> --- a/drivers/acpi/acpi_memhotplug.c
>>>> +++ b/drivers/acpi/acpi_memhotplug.c
>>>> @@ -220,15 +220,6 @@ static int acpi_memory_enable_device(struct
>>>>  	acpi_memory_device *mem_device) struct acpi_memory_info *info;
>>>>  	int node;
>>>>
>>>> -
>>>> -	/* Get the range from the _CRS */
>>>> -	result = acpi_memory_get_device_resources(mem_device);
>>>> -	if (result) {
>>>> -		printk(KERN_ERR PREFIX "get_device_resources failed\n");
>>>> -		mem_device->state = MEMORY_INVALID_STATE;
>>>> -		return result;
>>>> -	}
>>>> -
>>>>  	node = acpi_get_node(mem_device->device->handle);  	/*
>>>>  	 * Tell the VM there is more memory here...
>>>> @@ -357,14 +348,6 @@ static void
>>>>  		acpi_memory_device_notify(acpi_handle handle, u32 event, void
>>>> *data)  			break; } 
>>>>
>>>> -		if (acpi_memory_check_device(mem_device))
>>>> -			break;
>>
>> Hmm, if acpi_memory_check_device() fails, it means the memory device
>> disappears 
>> I don't know if a real hardware uses this way to remove memory device.
>>
>>>> -
>>>> -		if (acpi_memory_enable_device(mem_device)) {
>>>> -			printk(KERN_ERR PREFIX "Cannot enable memory device\n");
>>>> -			break;
>>>> -		}
>>
>> If acpi_memory_get_device() doesn't fail, it means that the device
>> has been managed by this driver, so I think we can do this cleanup.
>>
>> Thanks
>> Wen Congyang
>>
> 
> Thanks! any comments from Huawei side, Jiang?
Hi Jinsong,

We think it's ok.

acpi_memory_device_notify
	acpi_memory_get_device
		acpi_memory_device_add
			acpi_memory_get_device_resources
			acpi_memory_enable_device
				acpi_memory_get_device_resources(redundant)
	acpi_memory_check_device(redundant)
	acpi_memory_enable_device(redundant)


  reply	other threads:[~2012-12-13  2:36 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-04  1:39 [PATCH] X86/acpi: remove redundant logic of acpi memory hotadd Liu, Jinsong
2012-12-06 15:58 ` Liu, Jinsong
2012-12-07 22:19 ` Rafael J. Wysocki
2012-12-08  2:34   ` Wen Congyang
2012-12-12 14:37     ` Liu, Jinsong
2012-12-13  2:36       ` Jiang Liu [this message]
2012-12-13  2:36         ` Jiang Liu
2012-12-13 11:15         ` Rafael J. Wysocki
2012-12-13 11:15           ` Rafael J. Wysocki
2012-12-13 13:22           ` Liu, Jinsong
2012-12-13 13:22             ` Liu, Jinsong
  -- strict thread matches above, loose matches on Subject: below --
2012-11-14 11:47 Liu, Jinsong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50C93F36.4030402@huawei.com \
    --to=jiang.liu@huawei.com \
    --cc=jinsong.liu@intel.com \
    --cc=konrad.wilk@oracle.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=rjw@sisk.pl \
    --cc=toshi.kani@hp.com \
    --cc=wency@cn.fujitsu.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.