Hi,
On Mon, Apr 15, 2019 at 10:05:18AM +0800, Chen Zhou wrote:
> Hi Mike,
>
> On 2019/4/14 20:10, Mike Rapoport wrote:
> >>
> >> solution A:phys_addr_t start[INIT_MEMBLOCK_RESERVED_REGIONS * 2];
> >>phys_addr_t end[INIT_MEMBLOCK_RESERVED_REGIONS * 2];
> >> start, end is physic
On Mon, Apr 15, 2019 at 10:27:30AM +0800, Chen Zhou wrote:
> Hi Mike,
>
> On 2019/4/14 20:13, Mike Rapoport wrote:
> > Hi,
> >
> > On Tue, Apr 09, 2019 at 06:28:18PM +0800, Chen Zhou wrote:
> >> After commit (arm64: kdump: support reserving crashkernel above 4G),
> >> there may be two crash kerne
Hi Mike,
On 2019/4/14 20:13, Mike Rapoport wrote:
> Hi,
>
> On Tue, Apr 09, 2019 at 06:28:18PM +0800, Chen Zhou wrote:
>> After commit (arm64: kdump: support reserving crashkernel above 4G),
>> there may be two crash kernel regions, one is below 4G, the other is
>> above 4G.
>>
>> Crash dump kern
Hi Mike,
On 2019/4/14 20:10, Mike Rapoport wrote:
> Hi,
>
> On Thu, Apr 11, 2019 at 08:17:43PM +0800, Chen Zhou wrote:
>> Hi Mike,
>>
>> This overall looks well.
>> Replacing memblock_cap_memory_range() with memblock_cap_memory_ranges() was
>> what i wanted
>> to do in v1, sorry for don't expres
Hi,
On Tue, Apr 09, 2019 at 06:28:18PM +0800, Chen Zhou wrote:
> After commit (arm64: kdump: support reserving crashkernel above 4G),
> there may be two crash kernel regions, one is below 4G, the other is
> above 4G.
>
> Crash dump kernel reads more than one crash kernel regions via a dtb
> prope
Hi,
On Thu, Apr 11, 2019 at 08:17:43PM +0800, Chen Zhou wrote:
> Hi Mike,
>
> This overall looks well.
> Replacing memblock_cap_memory_range() with memblock_cap_memory_ranges() was
> what i wanted
> to do in v1, sorry for don't express that clearly.
I didn't object to memblock_cap_memory_ranges
