From patchwork Mon Mar 18 02:19:40 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yasuaki Ishimatsu X-Patchwork-Id: 2284571 Return-Path: X-Original-To: patchwork-linux-acpi@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork2.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork2.kernel.org (Postfix) with ESMTP id A0D16DFE82 for ; Mon, 18 Mar 2013 02:20:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751021Ab3CRCUl (ORCPT ); Sun, 17 Mar 2013 22:20:41 -0400 Received: from fgwmail6.fujitsu.co.jp ([192.51.44.36]:55379 "EHLO fgwmail6.fujitsu.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750936Ab3CRCUk (ORCPT ); Sun, 17 Mar 2013 22:20:40 -0400 Received: from m4.gw.fujitsu.co.jp (unknown [10.0.50.74]) by fgwmail6.fujitsu.co.jp (Postfix) with ESMTP id 2545B3EE0BB; Mon, 18 Mar 2013 11:20:37 +0900 (JST) Received: from smail (m4 [127.0.0.1]) by outgoing.m4.gw.fujitsu.co.jp (Postfix) with ESMTP id 0874845DE4F; Mon, 18 Mar 2013 11:20:37 +0900 (JST) Received: from s4.gw.fujitsu.co.jp (s4.gw.fujitsu.co.jp [10.0.50.94]) by m4.gw.fujitsu.co.jp (Postfix) with ESMTP id D9B6945DE53; Mon, 18 Mar 2013 11:20:36 +0900 (JST) Received: from s4.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s4.gw.fujitsu.co.jp (Postfix) with ESMTP id C743D1DB802F; Mon, 18 Mar 2013 11:20:36 +0900 (JST) Received: from G01JPEXCHYT27.g01.fujitsu.local (G01JPEXCHYT27.g01.fujitsu.local [10.128.193.110]) by s4.gw.fujitsu.co.jp (Postfix) with ESMTP id 73E36E08002; Mon, 18 Mar 2013 11:20:36 +0900 (JST) Received: from [127.0.0.1] (10.124.101.33) by G01JPEXCHYT27.g01.fujitsu.local (10.128.193.110) with Microsoft SMTP Server id 14.2.309.2; Mon, 18 Mar 2013 11:20:31 +0900 X-SecurityPolicyCheck: OK by SHieldMailChecker v1.7.4 Message-ID: <514679BC.5020700@jp.fujitsu.com> Date: Mon, 18 Mar 2013 11:19:40 +0900 From: Yasuaki Ishimatsu User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Toshi Kani CC: , , , , , Subject: [PATCH] Remove acpi_memory_info->failed bit References: <514022BF.3080303@jp.fujitsu.com> <1363186213.12845.174.camel@misato.fc.hp.com> In-Reply-To: <1363186213.12845.174.camel@misato.fc.hp.com> Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org Hi Toshi, Sorry for the late reply 2013/03/13 23:50, Toshi Kani wrote: > On Wed, 2013-03-13 at 15:54 +0900, Yasuaki Ishimatsu wrote: >> At http://marc.info/?l=linux-acpi&m=135769405622667&w=2 thread, >> Toshi Kani mentioned as follows: >> >> "I have a question about the change you made in commit 65479472 in >> acpi_memhotplug.c. This change seems to require that >> acpi_memory_enable_device() calls add_memory() to add all memory ranges >> represented by memory device objects at boot-time, and keep the results >> be used for hot-remove. >> >> If I understand it right, this add_memory() call fails with EEXIST at >> boot-time since all memory ranges should have been added from EFI memory >> table (or e820) already. This results all memory ranges be marked as ! >> enabled & !failed. I think this means that we cannot hot-delete any >> memory ranges presented at boot-time since acpi_memory_remove_memory() >> only calls remove_memory() when the enabled flag is set. Is that >> correct?" >> >> Above mention is correct. Thus even if memory device supports hotplug, >> memory presented at boot-time cannot be hot removed since the memory >> device's acpi_memory_info->enabled is always 0. >> >> This patch changes to set 1 to "acpi_memory_info->enabled" of memory >> device presented at boot-time for hot removing the memory device. >> >> Signed-off-by: Yasuaki Ishimatsu >> >> --- >> drivers/acpi/acpi_memhotplug.c | 4 ++-- >> 1 files changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c >> index da1f82b..88fd46a 100644 >> --- a/drivers/acpi/acpi_memhotplug.c >> +++ b/drivers/acpi/acpi_memhotplug.c >> @@ -254,8 +254,8 @@ static int acpi_memory_enable_device(struct acpi_memory_device *mem_device) >> continue; >> } >> >> - if (!result) >> - info->enabled = 1; >> + info->enabled = 1; > > Do we still need to keep the enable bit? I think !failed means enabled > with this change. For controlling memory hotplug, we need either failed bit or enabled bit. So I want to remove failed bit as follows: --- acpi_memory_info has enabled bit and failed bit for controlling memory hotplug. But we don't need to keep both bits. The patch removes acpi_memory_info->failed bit. Signed-off-by: Yasuaki Ishimatsu --- drivers/acpi/acpi_memhotplug.c | 15 ++------------- 1 files changed, 2 insertions(+), 13 deletions(-) -- 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 diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c index 88fd46a..cf4e1cf 100644 --- a/drivers/acpi/acpi_memhotplug.c +++ b/drivers/acpi/acpi_memhotplug.c @@ -79,7 +79,6 @@ struct acpi_memory_info { unsigned short caching; /* memory cache attribute */ unsigned short write_protect; /* memory read/write attribute */ unsigned int enabled:1; - unsigned int failed:1; }; struct acpi_memory_device { @@ -249,10 +248,8 @@ static int acpi_memory_enable_device(struct acpi_memory_device *mem_device) * returns -EEXIST. If add_memory() returns the other error, it * means that this memory block is not used by the kernel. */ - if (result && result != -EEXIST) { - info->failed = 1; + if (result && result != -EEXIST) continue; - } info->enabled = 1; @@ -286,16 +283,8 @@ static int acpi_memory_remove_memory(struct acpi_memory_device *mem_device) nid = acpi_get_node(mem_device->device->handle); list_for_each_entry_safe(info, n, &mem_device->res_list, list) { - if (info->failed) - /* The kernel does not use this memory block */ - continue; - if (!info->enabled) - /* - * The kernel uses this memory block, but it may be not - * managed by us. - */ - return -EBUSY; + continue; if (nid < 0) nid = memory_add_physaddr_to_nid(info->start_addr);