[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4FFD9C08.2070502@linux.vnet.ibm.com>
Date: Wed, 11 Jul 2012 08:30:16 -0700
From: Dave Hansen <dave@...ux.vnet.ibm.com>
To: Yasuaki Ishimatsu <isimatu.yasuaki@...fujitsu.com>
CC: linux-mm@...ck.org, linux-kernel@...r.kernel.org,
linuxppc-dev@...ts.ozlabs.org, linux-acpi@...r.kernel.org,
rientjes@...gle.com, liuj97@...il.com, len.brown@...el.com,
benh@...nel.crashing.org, paulus@...ba.org, cl@...ux.com,
minchan.kim@...il.com, akpm@...ux-foundation.org,
kosaki.motohiro@...fujitsu.com, wency@...fujitsu.com
Subject: Re: [RFC PATCH v3 3/13] memory-hotplug : unify argument of firmware_map_add_early/hotplug
On 07/09/2012 03:25 AM, Yasuaki Ishimatsu wrote:
> @@ -642,7 +642,7 @@ int __ref add_memory(int nid, u64 start,
> }
>
> /* create new memmap entry */
> - firmware_map_add_hotplug(start, start + size, "System RAM");
> + firmware_map_add_hotplug(start, start + size - 1, "System RAM");
I know the firmware_map_*() calls use inclusive end addresses
internally, but do we really need to expose them? Both of the callers
you mentioned do:
firmware_map_add_hotplug(start, start + size - 1, "System RAM");
or
firmware_map_add_early(entry->addr,
entry->addr + entry->size - 1,
e820_type_to_string(entry->type));
So it seems a _bit_ silly to keep all of the callers doing this size-1
thing. I also noted that the new caller that you added does the same
thing. Could we just change the external calling convention to be
exclusive?
BTW, this patch should probably be first in your series. It's a real
bugfix.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists