Re: [PATCH v2 3/8] powerpc/mm: Separate ibm, dynamic-memory data from DT format
Nathan Fontenot writes: > On 11/12/2017 06:43 AM, Michael Ellerman wrote: ... >> The bigger problem we have though is that you're trying to allocate >> memory, in order to find out what memory we have :) >> >> I suspect it works in some cases because you hit the memory@0 node first >> in the device tree, and add that memory to memblock, which means >> init_drmem_lmbs() *can* allocate memory, and everything's good. >> >> But if we hit init_drmem_lmbs() first, or there's not enough space in >> memory@0, then allocating memory in order to discover memory is not >> going to work. >> >> I'm not sure what the best solution is. One option would be to >> statically allocate some space, so that we can discover some of the LMBs >> without doing an allocation. But we wouldn't be able to guarantee that >> we had enough space i nthat static allocation, so the code would need to >> handle doing that and then potentially finding more LMBs later using a >> dynamic alloc. So that could be a bit messy. >> >> The other option would be for the early_init_dt_scan_drmem_lmbs() code >> to still work on the device tree directly, rather than using the >> drmem_info array. That would make for uglier code, but may be necessary. > > I have been thinking about my initial approach, and the more I look at it > the more I do not like trying to do the bootmem allocation. As you mention > there is just too much that could go wrong with that. > > I have started looking at a design where an interface similar to > walk_memory_range() is used for the prom and numa code so we do not have to > rely > on making the allocation for the lmb array early in boot. The lmb array > could then be allocated in the late_initcall in drmem.c at which point > the general kernel allocator is available. > > I'm still working on getting this coded up and when send out a new patch set > once it's ready unless anyone has objections to this approach. Thanks. That sounds like it could work. I definitely liked this version in that it removed a lot of code that was looking directly at the device tree and abstracted it to just operate on the LMBs. If we can end up with something similar but without needing to do the allocation before we have memory, that'd be great. cheers
Re: [PATCH v2 3/8] powerpc/mm: Separate ibm, dynamic-memory data from DT format
On 11/12/2017 06:43 AM, Michael Ellerman wrote:
> Hi Nathan,
>
> Nathan Fontenot writes:
>> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
>> index f83056297441..917184c13890 100644
>> --- a/arch/powerpc/kernel/prom.c
>> +++ b/arch/powerpc/kernel/prom.c
>> @@ -454,92 +455,93 @@ static int __init
>> early_init_dt_scan_chosen_ppc(unsigned long node,
> ...
>>
>> static int __init early_init_dt_scan_memory_ppc(unsigned long node,
>> const char *uname,
>> int depth, void *data)
>> {
>> +int rc;
>> +
>> if (depth == 1 &&
>> -strcmp(uname, "ibm,dynamic-reconfiguration-memory") == 0)
>> -return early_init_dt_scan_drconf_memory(node);
>> +strcmp(uname, "ibm,dynamic-reconfiguration-memory") == 0) {
>> +rc = init_drmem_lmbs(node);
>> +if (!rc)
>> +early_init_dt_scan_drmem_lmbs(node);
>> +
>> +return rc;
>> +}
>>
>> return early_init_dt_scan_memory(node, uname, depth, data);
>> }
>
> There's one bug in here which is that you return rc as returned by
> init_drmem_lmbs(). Returning non-zero from these scan routines
> terminates the scan, which means if anything goes wrong in
> init_drmem_lmbs() we may not call early_init_dt_scan_memory()
> in which case we won't have any memory at all.
>
I didn't know this would stop scanning the device tree, thanks for letting me
know.
> I say "may not" because it depends on the order of the nodes in the
> device tree whether you hit the memory nodes or the dynamic reconfig mem
> info first. And the order of the nodes in the device tree is arbitrary
> so we can't rely on that.
>
>
>> diff --git a/arch/powerpc/mm/drmem.c b/arch/powerpc/mm/drmem.c
>> new file mode 100644
>> index ..8ad7cf36b2c4
>> --- /dev/null
>> +++ b/arch/powerpc/mm/drmem.c
>> @@ -0,0 +1,84 @@
> ...
>> +
>> +int __init init_drmem_lmbs(unsigned long node)
>> +{
>> +struct drmem_lmb *lmb;
>> +const __be32 *prop;
>> +int prop_sz;
>> +u32 len;
>> +
>> +prop = of_get_flat_dt_prop(node, "ibm,lmb-size", &len);
>> +if (!prop || len < dt_root_size_cells * sizeof(__be32))
>> +return -1;
>> +
>> +drmem_info->lmb_size = dt_mem_next_cell(dt_root_size_cells, &prop);
>> +
>> +prop = of_get_flat_dt_prop(node, "ibm,dynamic-memory", &len);
>> +if (!prop || len < dt_root_size_cells * sizeof(__be32))
>> +return -1;
>> +
>> +drmem_info->n_lmbs = of_read_number(prop++, 1);
>> +prop_sz = drmem_info->n_lmbs * sizeof(struct of_drconf_cell)
>> + + sizeof(__be32);
>> +if (prop_sz < len)
>> +return -1;
>> +
>> +drmem_info->lmbs = alloc_bootmem(drmem_info->n_lmbs * sizeof(*lmb));
>> +if (!drmem_info->lmbs)
>> +return -1;
>
> The bigger problem we have though is that you're trying to allocate
> memory, in order to find out what memory we have :)
>
> I suspect it works in some cases because you hit the memory@0 node first
> in the device tree, and add that memory to memblock, which means
> init_drmem_lmbs() *can* allocate memory, and everything's good.
>
> But if we hit init_drmem_lmbs() first, or there's not enough space in
> memory@0, then allocating memory in order to discover memory is not
> going to work.
>
> I'm not sure what the best solution is. One option would be to
> statically allocate some space, so that we can discover some of the LMBs
> without doing an allocation. But we wouldn't be able to guarantee that
> we had enough space i nthat static allocation, so the code would need to
> handle doing that and then potentially finding more LMBs later using a
> dynamic alloc. So that could be a bit messy.
>
> The other option would be for the early_init_dt_scan_drmem_lmbs() code
> to still work on the device tree directly, rather than using the
> drmem_info array. That would make for uglier code, but may be necessary.
>
I have been thinking about my initial approach, and the more I look at it
the more I do not like trying to do the bootmem allocation. As you mention
there is just too much that could go wrong with that.
I have started looking at a design where an interface similar to
walk_memory_range() is used for the prom and numa code so we do not have to rely
on making the allocation for the lmb array early in boot. The lmb array
could then be allocated in the late_initcall in drmem.c at which point
the general kernel allocator is available.
I'm still working on getting this coded up and when send out a new patch set
once it's ready unless anyone has objections to this approach.
-Nathan
Re: [PATCH v2 3/8] powerpc/mm: Separate ibm, dynamic-memory data from DT format
Hi Nathan,
Nathan Fontenot writes:
> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
> index f83056297441..917184c13890 100644
> --- a/arch/powerpc/kernel/prom.c
> +++ b/arch/powerpc/kernel/prom.c
> @@ -454,92 +455,93 @@ static int __init
> early_init_dt_scan_chosen_ppc(unsigned long node,
...
>
> static int __init early_init_dt_scan_memory_ppc(unsigned long node,
> const char *uname,
> int depth, void *data)
> {
> + int rc;
> +
> if (depth == 1 &&
> - strcmp(uname, "ibm,dynamic-reconfiguration-memory") == 0)
> - return early_init_dt_scan_drconf_memory(node);
> + strcmp(uname, "ibm,dynamic-reconfiguration-memory") == 0) {
> + rc = init_drmem_lmbs(node);
> + if (!rc)
> + early_init_dt_scan_drmem_lmbs(node);
> +
> + return rc;
> + }
>
> return early_init_dt_scan_memory(node, uname, depth, data);
> }
There's one bug in here which is that you return rc as returned by
init_drmem_lmbs(). Returning non-zero from these scan routines
terminates the scan, which means if anything goes wrong in
init_drmem_lmbs() we may not call early_init_dt_scan_memory()
in which case we won't have any memory at all.
I say "may not" because it depends on the order of the nodes in the
device tree whether you hit the memory nodes or the dynamic reconfig mem
info first. And the order of the nodes in the device tree is arbitrary
so we can't rely on that.
> diff --git a/arch/powerpc/mm/drmem.c b/arch/powerpc/mm/drmem.c
> new file mode 100644
> index ..8ad7cf36b2c4
> --- /dev/null
> +++ b/arch/powerpc/mm/drmem.c
> @@ -0,0 +1,84 @@
...
> +
> +int __init init_drmem_lmbs(unsigned long node)
> +{
> + struct drmem_lmb *lmb;
> + const __be32 *prop;
> + int prop_sz;
> + u32 len;
> +
> + prop = of_get_flat_dt_prop(node, "ibm,lmb-size", &len);
> + if (!prop || len < dt_root_size_cells * sizeof(__be32))
> + return -1;
> +
> + drmem_info->lmb_size = dt_mem_next_cell(dt_root_size_cells, &prop);
> +
> + prop = of_get_flat_dt_prop(node, "ibm,dynamic-memory", &len);
> + if (!prop || len < dt_root_size_cells * sizeof(__be32))
> + return -1;
> +
> + drmem_info->n_lmbs = of_read_number(prop++, 1);
> + prop_sz = drmem_info->n_lmbs * sizeof(struct of_drconf_cell)
> + + sizeof(__be32);
> + if (prop_sz < len)
> + return -1;
> +
> + drmem_info->lmbs = alloc_bootmem(drmem_info->n_lmbs * sizeof(*lmb));
> + if (!drmem_info->lmbs)
> + return -1;
The bigger problem we have though is that you're trying to allocate
memory, in order to find out what memory we have :)
I suspect it works in some cases because you hit the memory@0 node first
in the device tree, and add that memory to memblock, which means
init_drmem_lmbs() *can* allocate memory, and everything's good.
But if we hit init_drmem_lmbs() first, or there's not enough space in
memory@0, then allocating memory in order to discover memory is not
going to work.
I'm not sure what the best solution is. One option would be to
statically allocate some space, so that we can discover some of the LMBs
without doing an allocation. But we wouldn't be able to guarantee that
we had enough space i nthat static allocation, so the code would need to
handle doing that and then potentially finding more LMBs later using a
dynamic alloc. So that could be a bit messy.
The other option would be for the early_init_dt_scan_drmem_lmbs() code
to still work on the device tree directly, rather than using the
drmem_info array. That would make for uglier code, but may be necessary.
cheers
Re: [PATCH v2 3/8] powerpc/mm: Separate ibm, dynamic-memory data from DT format
Nathan Fontenot writes:
> On 10/24/2017 01:08 AM, Michael Ellerman wrote:
>> Nathan Fontenot writes:
>>
>>> diff --git a/arch/powerpc/mm/drmem.c b/arch/powerpc/mm/drmem.c
>>> new file mode 100644
>>> index ..8ad7cf36b2c4
>>> --- /dev/null
>>> +++ b/arch/powerpc/mm/drmem.c
>>> @@ -0,0 +1,84 @@
>>> +/*
>>> + * Dynamic reconfiguration memory support
>>> + *
>>> + * Copyright 2017 IBM Corporation
>>> + *
>>> + * 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.
>>> + */
>>> +
>>> +#define pr_fmt(fmt) "drmem: " fmt
>>> +
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +
>>> +static struct drmem_lmb_info __drmem_info;
>>> +struct drmem_lmb_info *drmem_info = &__drmem_info;
>>> +
>>> +int __init init_drmem_lmbs(unsigned long node)
>>> +{
>>
>> Something in here is blowing up for me.
>>
>> This is a p8 LPAR, which uses petitboot so we kexec into the kernel,
>> gives me:
>>
>> [ 29.020618] kexec_core: Starting new kernel
>> [0.00] bootconsole [udbg0] enabled
>>-> early_setup(), dt_ptr: 0x1ec6
>> [0.00] bootmem alloc of 3024 bytes failed!
>> [0.00] Kernel panic - not syncing: Out of memory
>> [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted
>> 4.14.0-rc2-gcc6-gf7212f8 #1
>> [0.00] Call Trace:
>> [0.00] [c0f57b80] [c0a2bae0] dump_stack+0xb0/0xf0
>> (unreliable)
>> [0.00] [c0f57bc0] [c00fcdb0] panic+0x148/0x338
>> [0.00] [c0f57c60] [c0d4bb08]
>> ___alloc_bootmem.part.1+0x3c/0x40
>> [0.00] [c0f57cc0] [c0d4bf18]
>> __alloc_bootmem+0x3c/0x50
>> [0.00] [c0f57cf0] [c0d226c4]
>> init_drmem_lmbs+0xf8/0x31c
>> [0.00] [c0f57d70] [c0d1a05c]
>> early_init_dt_scan_memory_ppc+0x88/0x25c
>> [0.00] [c0f57e10] [00d78e78] 0xd78e78
>> [0.00] [c0f57e70] [00d1a92c] 0xd1a92c
>> [0.00] [c0f57f10] [00d1be3c] 0xd1be3c
>> [0.00] [c0f57f90] [b13c] 0xb13c
>> [0.00] Rebooting in 180 seconds..
>> [0.00] System Halted, OK to turn off power
>>
>>
>
> Looks like we're out of memory when trying to allocate the LMB array, not
> sure why.
> I'll try to re-create this on one of my systems.
Thanks.
> I found a patch where you tried to remove traces of bootmem from a couple of
> yearts ago. Not sure if it make a difference but should I be using
> memblock_virt_alloc() instead of alloc_bootmem()?
Yes.
Though it *shouldn't* matter, because alloc_bootmem() will use the
version in mm/nobootmem.c which eventually calls memblock anyway.
But we are trying to get rid of bootmem entirely so you should use
memblock directly in new code.
cheers
Re: [PATCH v2 3/8] powerpc/mm: Separate ibm, dynamic-memory data from DT format
On 10/24/2017 01:08 AM, Michael Ellerman wrote:
> Nathan Fontenot writes:
>
>> diff --git a/arch/powerpc/mm/drmem.c b/arch/powerpc/mm/drmem.c
>> new file mode 100644
>> index ..8ad7cf36b2c4
>> --- /dev/null
>> +++ b/arch/powerpc/mm/drmem.c
>> @@ -0,0 +1,84 @@
>> +/*
>> + * Dynamic reconfiguration memory support
>> + *
>> + * Copyright 2017 IBM Corporation
>> + *
>> + * 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.
>> + */
>> +
>> +#define pr_fmt(fmt) "drmem: " fmt
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +static struct drmem_lmb_info __drmem_info;
>> +struct drmem_lmb_info *drmem_info = &__drmem_info;
>> +
>> +int __init init_drmem_lmbs(unsigned long node)
>> +{
>
> Something in here is blowing up for me.
>
> This is a p8 LPAR, which uses petitboot so we kexec into the kernel,
> gives me:
>
> [ 29.020618] kexec_core: Starting new kernel
> [0.00] bootconsole [udbg0] enabled
>-> early_setup(), dt_ptr: 0x1ec6
> [0.00] bootmem alloc of 3024 bytes failed!
> [0.00] Kernel panic - not syncing: Out of memory
> [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted
> 4.14.0-rc2-gcc6-gf7212f8 #1
> [0.00] Call Trace:
> [0.00] [c0f57b80] [c0a2bae0] dump_stack+0xb0/0xf0
> (unreliable)
> [0.00] [c0f57bc0] [c00fcdb0] panic+0x148/0x338
> [0.00] [c0f57c60] [c0d4bb08]
> ___alloc_bootmem.part.1+0x3c/0x40
> [0.00] [c0f57cc0] [c0d4bf18]
> __alloc_bootmem+0x3c/0x50
> [0.00] [c0f57cf0] [c0d226c4]
> init_drmem_lmbs+0xf8/0x31c
> [0.00] [c0f57d70] [c0d1a05c]
> early_init_dt_scan_memory_ppc+0x88/0x25c
> [0.00] [c0f57e10] [00d78e78] 0xd78e78
> [0.00] [c0f57e70] [00d1a92c] 0xd1a92c
> [0.00] [c0f57f10] [00d1be3c] 0xd1be3c
> [0.00] [c0f57f90] [b13c] 0xb13c
> [0.00] Rebooting in 180 seconds..
> [0.00] System Halted, OK to turn off power
>
>
Looks like we're out of memory when trying to allocate the LMB array, not sure
why.
I'll try to re-create this on one of my systems.
I found a patch where you tried to remove traces of bootmem from a couple of
yearts ago. Not sure if it make a difference but should I be using
memblock_virt_alloc() instead of alloc_bootmem()?
-Nathan
> I'm at kernel summit so haven't had time to look any further sorry.
>
> cheers
>
Re: [PATCH v2 3/8] powerpc/mm: Separate ibm, dynamic-memory data from DT format
Nathan Fontenot writes:
> diff --git a/arch/powerpc/mm/drmem.c b/arch/powerpc/mm/drmem.c
> new file mode 100644
> index ..8ad7cf36b2c4
> --- /dev/null
> +++ b/arch/powerpc/mm/drmem.c
> @@ -0,0 +1,84 @@
> +/*
> + * Dynamic reconfiguration memory support
> + *
> + * Copyright 2017 IBM Corporation
> + *
> + * 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.
> + */
> +
> +#define pr_fmt(fmt) "drmem: " fmt
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static struct drmem_lmb_info __drmem_info;
> +struct drmem_lmb_info *drmem_info = &__drmem_info;
> +
> +int __init init_drmem_lmbs(unsigned long node)
> +{
Something in here is blowing up for me.
This is a p8 LPAR, which uses petitboot so we kexec into the kernel,
gives me:
[ 29.020618] kexec_core: Starting new kernel
[0.00] bootconsole [udbg0] enabled
-> early_setup(), dt_ptr: 0x1ec6
[0.00] bootmem alloc of 3024 bytes failed!
[0.00] Kernel panic - not syncing: Out of memory
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted
4.14.0-rc2-gcc6-gf7212f8 #1
[0.00] Call Trace:
[0.00] [c0f57b80] [c0a2bae0] dump_stack+0xb0/0xf0
(unreliable)
[0.00] [c0f57bc0] [c00fcdb0] panic+0x148/0x338
[0.00] [c0f57c60] [c0d4bb08]
___alloc_bootmem.part.1+0x3c/0x40
[0.00] [c0f57cc0] [c0d4bf18] __alloc_bootmem+0x3c/0x50
[0.00] [c0f57cf0] [c0d226c4]
init_drmem_lmbs+0xf8/0x31c
[0.00] [c0f57d70] [c0d1a05c]
early_init_dt_scan_memory_ppc+0x88/0x25c
[0.00] [c0f57e10] [00d78e78] 0xd78e78
[0.00] [c0f57e70] [00d1a92c] 0xd1a92c
[0.00] [c0f57f10] [00d1be3c] 0xd1be3c
[0.00] [c0f57f90] [b13c] 0xb13c
[0.00] Rebooting in 180 seconds..
[0.00] System Halted, OK to turn off power
I'm at kernel summit so haven't had time to look any further sorry.
cheers
[PATCH v2 3/8] powerpc/mm: Separate ibm, dynamic-memory data from DT format
We currently have code to parse the dynamic reconfiguration LMB
information from the ibm,dynamic-meory device tree property in
multiple locations (numa.c, prom.c, and pseries/hotplug-memory.c).
In anticipation of adding support for a version 2 of the
ibm,dynamic-memory property this patch aims to separate the device
tree information from the device tree format.
To do this an array of per-LMB information is created at boot time
and any pieces of code that need to look at LMB information are then
updated to use this array instead of parsing the device tree directly.
Doing this provides several benefits. The device tree property
parsing is located in a single place, it makes walking through the
possible LMBs on a system easier, and provides a common data structure
so that any piece of the kernel needing LMB information does not
have to provide multiple parsing routines for the supported device
tree formats.
This patch consolidates the device tree parsing into a common
location and builds the LMB array at boot time in a new file
powerpc/mm/drmem.c This patch also updates the prom
code to use the new LMB array.
Signed-off-by: Nathan Fontenot
---
Updates for V2: Correct build break for non-pseries builds.
---
arch/powerpc/include/asm/drmem.h | 45 +
arch/powerpc/kernel/prom.c | 128 +++---
arch/powerpc/mm/Makefile |2 -
arch/powerpc/mm/drmem.c | 84 +
4 files changed, 195 insertions(+), 64 deletions(-)
create mode 100644 arch/powerpc/include/asm/drmem.h
create mode 100644 arch/powerpc/mm/drmem.c
diff --git a/arch/powerpc/include/asm/drmem.h b/arch/powerpc/include/asm/drmem.h
new file mode 100644
index ..cafe1a3b7da6
--- /dev/null
+++ b/arch/powerpc/include/asm/drmem.h
@@ -0,0 +1,45 @@
+/*
+ * drmem.h: Power specific logical memory block representation
+ *
+ * Copyright 2017 IBM Corporation
+ *
+ * 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.
+ */
+
+#ifndef _ASM_POWERPC_LMB_H
+#define _ASM_POWERPC_LMB_H
+
+struct drmem_lmb {
+ u64 base_addr;
+ u32 drc_index;
+ u32 aa_index;
+ u32 flags;
+};
+
+struct drmem_lmb_info {
+ struct drmem_lmb*lmbs;
+ int n_lmbs;
+ u32 lmb_size;
+};
+
+extern struct drmem_lmb_info *drmem_info;
+
+#define for_each_drmem_lmb_in_range(lmb, start, end) \
+ for ((lmb) = (start); (lmb) <= (end); (lmb)++)
+
+#define for_each_drmem_lmb(lmb)\
+ for_each_drmem_lmb_in_range((lmb), \
+ &drmem_info->lmbs[0], \
+ &drmem_info->lmbs[drmem_info->n_lmbs - 1])
+
+static inline u32 drmem_lmb_size(void)
+{
+ return drmem_info->lmb_size;
+}
+
+extern int __init init_drmem_lmbs(unsigned long node);
+
+#endif
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index f83056297441..917184c13890 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -58,6 +58,7 @@
#include
#include
#include
+#include
#include
@@ -454,92 +455,93 @@ static int __init early_init_dt_scan_chosen_ppc(unsigned
long node,
#ifdef CONFIG_PPC_PSERIES
/*
- * Interpret the ibm,dynamic-memory property in the
- * /ibm,dynamic-reconfiguration-memory node.
+ * Interpret the ibm dynamic reconfiguration memory LMBs.
* This contains a list of memory blocks along with NUMA affinity
* information.
*/
-static int __init early_init_dt_scan_drconf_memory(unsigned long node)
+
+static void __init add_drmem_lmb(struct drmem_lmb *lmb, const __be32 **usm)
{
- const __be32 *dm, *ls, *usm;
- int l;
- unsigned long n, flags;
- u64 base, size, memblock_size;
- unsigned int is_kexec_kdump = 0, rngs;
+ u64 base, size;
+ int is_kexec_kdump = 0, rngs;
- ls = of_get_flat_dt_prop(node, "ibm,lmb-size", &l);
- if (ls == NULL || l < dt_root_size_cells * sizeof(__be32))
- return 0;
- memblock_size = dt_mem_next_cell(dt_root_size_cells, &ls);
+ base = lmb->base_addr;
+ size = drmem_lmb_size();
+ rngs = 1;
- dm = of_get_flat_dt_prop(node, "ibm,dynamic-memory", &l);
- if (dm == NULL || l < sizeof(__be32))
- return 0;
+ if (*usm)
+ is_kexec_kdump = 1;
- n = of_read_number(dm++, 1);/* number of entries */
- if (l < (n * (dt_root_addr_cells + 4) + 1) * sizeof(__be32))
- return 0;
+ if (is_kexec_kdump) {
+ /*
+* For each memblock in ibm,dynamic-memory, a
+* corresponding entry in linux,drconf-usable-memory
+* pro
