From: Dennis Chen <dennis.chen@arm.com>
To: Will Deacon <will.deacon@arm.com>,
AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: mark.rutland@arm.com, kuleshovmail@gmail.com,
geoff@infradead.org, catalin.marinas@arm.com,
kexec@lists.infradead.org, linux-mm@kvack.org,
james.morse@arm.com, zijun_hu@htc.com,
bauerman@linux.vnet.ibm.com, tj@kernel.org,
akpm@linux-foundation.org, nd@arm.com, dyoung@redhat.com,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v29 1/9] memblock: add memblock_cap_memory_range()
Date: Wed, 11 Jan 2017 09:57:39 +0800 [thread overview]
Message-ID: <20170111015737.GA518@arm.com> (raw)
In-Reply-To: <20170110111617.GB21598@arm.com>
On Tue, Jan 10, 2017 at 11:16:18AM +0000, Will Deacon wrote:
> [adding some more folks to cc]
>
> On Wed, Dec 28, 2016 at 01:35:25PM +0900, AKASHI Takahiro wrote:
> > Add memblock_cap_memory_range() which will remove all the memblock regions
> > except the memory range specified in the arguments. In addition, rework is
> > done on memblock_mem_limit_remove_map() to re-implement it using
> > memblock_cap_memory_range().
> >
> > This function, like memblock_mem_limit_remove_map(), will not remove
> > memblocks with MEMMAP_NOMAP attribute as they may be mapped and accessed
> > later as "device memory."
> > See the commit a571d4eb55d8 ("mm/memblock.c: add new infrastructure to
> > address the mem limit issue").
> >
> > This function is used, in a succeeding patch in the series of arm64 kdump
> > suuport, to limit the range of usable memory, or System RAM, on crash dump
> > kernel.
> > (Please note that "mem=" parameter is of little use for this purpose.)
> >
> > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > Reviewed-by: Will Deacon <will.deacon@arm.com>
> > Acked-by: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: linux-mm@kvack.org
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > ---
> > include/linux/memblock.h | 1 +
> > mm/memblock.c | 44 +++++++++++++++++++++++++++++---------------
> > 2 files changed, 30 insertions(+), 15 deletions(-)
>
> Whilst this patch looks fine to me, it would be nice if Dennis (author of
> memblock_mem_limit_remove_map) or one of the mm chaps could provide an ack
> before I merge it via arm64.
>
Will feel free to add
Acked-by: Dennis Chen <dennis.chen@arm.com>
Thanks,
Dennis
>
> Thanks,
>
> Will
>
> > diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> > index 5b759c9acf97..fbfcacc50c29 100644
> > --- a/include/linux/memblock.h
> > +++ b/include/linux/memblock.h
> > @@ -333,6 +333,7 @@ phys_addr_t memblock_mem_size(unsigned long limit_pfn);
> > phys_addr_t memblock_start_of_DRAM(void);
> > phys_addr_t memblock_end_of_DRAM(void);
> > void memblock_enforce_memory_limit(phys_addr_t memory_limit);
> > +void memblock_cap_memory_range(phys_addr_t base, phys_addr_t size);
> > void memblock_mem_limit_remove_map(phys_addr_t limit);
> > bool memblock_is_memory(phys_addr_t addr);
> > int memblock_is_map_memory(phys_addr_t addr);
> > diff --git a/mm/memblock.c b/mm/memblock.c
> > index 7608bc305936..fea1688fef60 100644
> > --- a/mm/memblock.c
> > +++ b/mm/memblock.c
> > @@ -1514,11 +1514,37 @@ void __init memblock_enforce_memory_limit(phys_addr_t limit)
> > (phys_addr_t)ULLONG_MAX);
> > }
> >
> > +void __init memblock_cap_memory_range(phys_addr_t base, phys_addr_t size)
> > +{
> > + int start_rgn, end_rgn;
> > + int i, ret;
> > +
> > + if (!size)
> > + return;
> > +
> > + ret = memblock_isolate_range(&memblock.memory, base, size,
> > + &start_rgn, &end_rgn);
> > + if (ret)
> > + return;
> > +
> > + /* remove all the MAP regions */
> > + for (i = memblock.memory.cnt - 1; i >= end_rgn; i--)
> > + if (!memblock_is_nomap(&memblock.memory.regions[i]))
> > + memblock_remove_region(&memblock.memory, i);
> > +
> > + for (i = start_rgn - 1; i >= 0; i--)
> > + if (!memblock_is_nomap(&memblock.memory.regions[i]))
> > + memblock_remove_region(&memblock.memory, i);
> > +
> > + /* truncate the reserved regions */
> > + memblock_remove_range(&memblock.reserved, 0, base);
> > + memblock_remove_range(&memblock.reserved,
> > + base + size, (phys_addr_t)ULLONG_MAX);
> > +}
> > +
> > void __init memblock_mem_limit_remove_map(phys_addr_t limit)
> > {
> > - struct memblock_type *type = &memblock.memory;
> > phys_addr_t max_addr;
> > - int i, ret, start_rgn, end_rgn;
> >
> > if (!limit)
> > return;
> > @@ -1529,19 +1555,7 @@ void __init memblock_mem_limit_remove_map(phys_addr_t limit)
> > if (max_addr == (phys_addr_t)ULLONG_MAX)
> > return;
> >
> > - ret = memblock_isolate_range(type, max_addr, (phys_addr_t)ULLONG_MAX,
> > - &start_rgn, &end_rgn);
> > - if (ret)
> > - return;
> > -
> > - /* remove all the MAP regions above the limit */
> > - for (i = end_rgn - 1; i >= start_rgn; i--) {
> > - if (!memblock_is_nomap(&type->regions[i]))
> > - memblock_remove_region(type, i);
> > - }
> > - /* truncate the reserved regions */
> > - memblock_remove_range(&memblock.reserved, max_addr,
> > - (phys_addr_t)ULLONG_MAX);
> > + memblock_cap_memory_range(0, max_addr);
> > }
> >
> > static int __init_memblock memblock_search(struct memblock_type *type, phys_addr_t addr)
> > --
> > 2.11.0
> >
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: dennis.chen@arm.com (Dennis Chen)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v29 1/9] memblock: add memblock_cap_memory_range()
Date: Wed, 11 Jan 2017 09:57:39 +0800 [thread overview]
Message-ID: <20170111015737.GA518@arm.com> (raw)
In-Reply-To: <20170110111617.GB21598@arm.com>
On Tue, Jan 10, 2017 at 11:16:18AM +0000, Will Deacon wrote:
> [adding some more folks to cc]
>
> On Wed, Dec 28, 2016 at 01:35:25PM +0900, AKASHI Takahiro wrote:
> > Add memblock_cap_memory_range() which will remove all the memblock regions
> > except the memory range specified in the arguments. In addition, rework is
> > done on memblock_mem_limit_remove_map() to re-implement it using
> > memblock_cap_memory_range().
> >
> > This function, like memblock_mem_limit_remove_map(), will not remove
> > memblocks with MEMMAP_NOMAP attribute as they may be mapped and accessed
> > later as "device memory."
> > See the commit a571d4eb55d8 ("mm/memblock.c: add new infrastructure to
> > address the mem limit issue").
> >
> > This function is used, in a succeeding patch in the series of arm64 kdump
> > suuport, to limit the range of usable memory, or System RAM, on crash dump
> > kernel.
> > (Please note that "mem=" parameter is of little use for this purpose.)
> >
> > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > Reviewed-by: Will Deacon <will.deacon@arm.com>
> > Acked-by: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: linux-mm at kvack.org
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > ---
> > include/linux/memblock.h | 1 +
> > mm/memblock.c | 44 +++++++++++++++++++++++++++++---------------
> > 2 files changed, 30 insertions(+), 15 deletions(-)
>
> Whilst this patch looks fine to me, it would be nice if Dennis (author of
> memblock_mem_limit_remove_map) or one of the mm chaps could provide an ack
> before I merge it via arm64.
>
Will feel free to add
Acked-by: Dennis Chen <dennis.chen@arm.com>
Thanks,
Dennis
>
> Thanks,
>
> Will
>
> > diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> > index 5b759c9acf97..fbfcacc50c29 100644
> > --- a/include/linux/memblock.h
> > +++ b/include/linux/memblock.h
> > @@ -333,6 +333,7 @@ phys_addr_t memblock_mem_size(unsigned long limit_pfn);
> > phys_addr_t memblock_start_of_DRAM(void);
> > phys_addr_t memblock_end_of_DRAM(void);
> > void memblock_enforce_memory_limit(phys_addr_t memory_limit);
> > +void memblock_cap_memory_range(phys_addr_t base, phys_addr_t size);
> > void memblock_mem_limit_remove_map(phys_addr_t limit);
> > bool memblock_is_memory(phys_addr_t addr);
> > int memblock_is_map_memory(phys_addr_t addr);
> > diff --git a/mm/memblock.c b/mm/memblock.c
> > index 7608bc305936..fea1688fef60 100644
> > --- a/mm/memblock.c
> > +++ b/mm/memblock.c
> > @@ -1514,11 +1514,37 @@ void __init memblock_enforce_memory_limit(phys_addr_t limit)
> > (phys_addr_t)ULLONG_MAX);
> > }
> >
> > +void __init memblock_cap_memory_range(phys_addr_t base, phys_addr_t size)
> > +{
> > + int start_rgn, end_rgn;
> > + int i, ret;
> > +
> > + if (!size)
> > + return;
> > +
> > + ret = memblock_isolate_range(&memblock.memory, base, size,
> > + &start_rgn, &end_rgn);
> > + if (ret)
> > + return;
> > +
> > + /* remove all the MAP regions */
> > + for (i = memblock.memory.cnt - 1; i >= end_rgn; i--)
> > + if (!memblock_is_nomap(&memblock.memory.regions[i]))
> > + memblock_remove_region(&memblock.memory, i);
> > +
> > + for (i = start_rgn - 1; i >= 0; i--)
> > + if (!memblock_is_nomap(&memblock.memory.regions[i]))
> > + memblock_remove_region(&memblock.memory, i);
> > +
> > + /* truncate the reserved regions */
> > + memblock_remove_range(&memblock.reserved, 0, base);
> > + memblock_remove_range(&memblock.reserved,
> > + base + size, (phys_addr_t)ULLONG_MAX);
> > +}
> > +
> > void __init memblock_mem_limit_remove_map(phys_addr_t limit)
> > {
> > - struct memblock_type *type = &memblock.memory;
> > phys_addr_t max_addr;
> > - int i, ret, start_rgn, end_rgn;
> >
> > if (!limit)
> > return;
> > @@ -1529,19 +1555,7 @@ void __init memblock_mem_limit_remove_map(phys_addr_t limit)
> > if (max_addr == (phys_addr_t)ULLONG_MAX)
> > return;
> >
> > - ret = memblock_isolate_range(type, max_addr, (phys_addr_t)ULLONG_MAX,
> > - &start_rgn, &end_rgn);
> > - if (ret)
> > - return;
> > -
> > - /* remove all the MAP regions above the limit */
> > - for (i = end_rgn - 1; i >= start_rgn; i--) {
> > - if (!memblock_is_nomap(&type->regions[i]))
> > - memblock_remove_region(type, i);
> > - }
> > - /* truncate the reserved regions */
> > - memblock_remove_range(&memblock.reserved, max_addr,
> > - (phys_addr_t)ULLONG_MAX);
> > + memblock_cap_memory_range(0, max_addr);
> > }
> >
> > static int __init_memblock memblock_search(struct memblock_type *type, phys_addr_t addr)
> > --
> > 2.11.0
> >
WARNING: multiple messages have this Message-ID (diff)
From: Dennis Chen <dennis.chen@arm.com>
To: Will Deacon <will.deacon@arm.com>,
AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: catalin.marinas@arm.com, akpm@linux-foundation.org,
james.morse@arm.com, geoff@infradead.org,
bauerman@linux.vnet.ibm.com, dyoung@redhat.com,
mark.rutland@arm.com, kexec@lists.infradead.org,
linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org,
kuleshovmail@gmail.com, zijun_hu@htc.com,
tj@kernel.orgnd@arm.com
Subject: Re: [PATCH v29 1/9] memblock: add memblock_cap_memory_range()
Date: Wed, 11 Jan 2017 09:57:39 +0800 [thread overview]
Message-ID: <20170111015737.GA518@arm.com> (raw)
In-Reply-To: <20170110111617.GB21598@arm.com>
On Tue, Jan 10, 2017 at 11:16:18AM +0000, Will Deacon wrote:
> [adding some more folks to cc]
>
> On Wed, Dec 28, 2016 at 01:35:25PM +0900, AKASHI Takahiro wrote:
> > Add memblock_cap_memory_range() which will remove all the memblock regions
> > except the memory range specified in the arguments. In addition, rework is
> > done on memblock_mem_limit_remove_map() to re-implement it using
> > memblock_cap_memory_range().
> >
> > This function, like memblock_mem_limit_remove_map(), will not remove
> > memblocks with MEMMAP_NOMAP attribute as they may be mapped and accessed
> > later as "device memory."
> > See the commit a571d4eb55d8 ("mm/memblock.c: add new infrastructure to
> > address the mem limit issue").
> >
> > This function is used, in a succeeding patch in the series of arm64 kdump
> > suuport, to limit the range of usable memory, or System RAM, on crash dump
> > kernel.
> > (Please note that "mem=" parameter is of little use for this purpose.)
> >
> > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > Reviewed-by: Will Deacon <will.deacon@arm.com>
> > Acked-by: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: linux-mm@kvack.org
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > ---
> > include/linux/memblock.h | 1 +
> > mm/memblock.c | 44 +++++++++++++++++++++++++++++---------------
> > 2 files changed, 30 insertions(+), 15 deletions(-)
>
> Whilst this patch looks fine to me, it would be nice if Dennis (author of
> memblock_mem_limit_remove_map) or one of the mm chaps could provide an ack
> before I merge it via arm64.
>
Will feel free to add
Acked-by: Dennis Chen <dennis.chen@arm.com>
Thanks,
Dennis
>
> Thanks,
>
> Will
>
> > diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> > index 5b759c9acf97..fbfcacc50c29 100644
> > --- a/include/linux/memblock.h
> > +++ b/include/linux/memblock.h
> > @@ -333,6 +333,7 @@ phys_addr_t memblock_mem_size(unsigned long limit_pfn);
> > phys_addr_t memblock_start_of_DRAM(void);
> > phys_addr_t memblock_end_of_DRAM(void);
> > void memblock_enforce_memory_limit(phys_addr_t memory_limit);
> > +void memblock_cap_memory_range(phys_addr_t base, phys_addr_t size);
> > void memblock_mem_limit_remove_map(phys_addr_t limit);
> > bool memblock_is_memory(phys_addr_t addr);
> > int memblock_is_map_memory(phys_addr_t addr);
> > diff --git a/mm/memblock.c b/mm/memblock.c
> > index 7608bc305936..fea1688fef60 100644
> > --- a/mm/memblock.c
> > +++ b/mm/memblock.c
> > @@ -1514,11 +1514,37 @@ void __init memblock_enforce_memory_limit(phys_addr_t limit)
> > (phys_addr_t)ULLONG_MAX);
> > }
> >
> > +void __init memblock_cap_memory_range(phys_addr_t base, phys_addr_t size)
> > +{
> > + int start_rgn, end_rgn;
> > + int i, ret;
> > +
> > + if (!size)
> > + return;
> > +
> > + ret = memblock_isolate_range(&memblock.memory, base, size,
> > + &start_rgn, &end_rgn);
> > + if (ret)
> > + return;
> > +
> > + /* remove all the MAP regions */
> > + for (i = memblock.memory.cnt - 1; i >= end_rgn; i--)
> > + if (!memblock_is_nomap(&memblock.memory.regions[i]))
> > + memblock_remove_region(&memblock.memory, i);
> > +
> > + for (i = start_rgn - 1; i >= 0; i--)
> > + if (!memblock_is_nomap(&memblock.memory.regions[i]))
> > + memblock_remove_region(&memblock.memory, i);
> > +
> > + /* truncate the reserved regions */
> > + memblock_remove_range(&memblock.reserved, 0, base);
> > + memblock_remove_range(&memblock.reserved,
> > + base + size, (phys_addr_t)ULLONG_MAX);
> > +}
> > +
> > void __init memblock_mem_limit_remove_map(phys_addr_t limit)
> > {
> > - struct memblock_type *type = &memblock.memory;
> > phys_addr_t max_addr;
> > - int i, ret, start_rgn, end_rgn;
> >
> > if (!limit)
> > return;
> > @@ -1529,19 +1555,7 @@ void __init memblock_mem_limit_remove_map(phys_addr_t limit)
> > if (max_addr == (phys_addr_t)ULLONG_MAX)
> > return;
> >
> > - ret = memblock_isolate_range(type, max_addr, (phys_addr_t)ULLONG_MAX,
> > - &start_rgn, &end_rgn);
> > - if (ret)
> > - return;
> > -
> > - /* remove all the MAP regions above the limit */
> > - for (i = end_rgn - 1; i >= start_rgn; i--) {
> > - if (!memblock_is_nomap(&type->regions[i]))
> > - memblock_remove_region(type, i);
> > - }
> > - /* truncate the reserved regions */
> > - memblock_remove_range(&memblock.reserved, max_addr,
> > - (phys_addr_t)ULLONG_MAX);
> > + memblock_cap_memory_range(0, max_addr);
> > }
> >
> > static int __init_memblock memblock_search(struct memblock_type *type, phys_addr_t addr)
> > --
> > 2.11.0
> >
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2017-01-11 1:57 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-28 4:33 [PATCH v29 0/9] arm64: add kdump support AKASHI Takahiro
2016-12-28 4:33 ` AKASHI Takahiro
2016-12-28 4:35 ` [PATCH v29 1/9] memblock: add memblock_cap_memory_range() AKASHI Takahiro
2016-12-28 4:35 ` AKASHI Takahiro
2016-12-28 4:35 ` AKASHI Takahiro
2017-01-10 11:16 ` Will Deacon
2017-01-10 11:16 ` Will Deacon
2017-01-10 11:16 ` Will Deacon
2017-01-11 1:57 ` Dennis Chen [this message]
2017-01-11 1:57 ` Dennis Chen
2017-01-11 1:57 ` Dennis Chen
2016-12-28 4:35 ` [PATCH v29 2/9] arm64: limit memory regions based on DT property, usable-memory-range AKASHI Takahiro
2016-12-28 4:35 ` AKASHI Takahiro
2016-12-28 4:36 ` [PATCH v29 3/9] arm64: kdump: reserve memory for crash dump kernel AKASHI Takahiro
2016-12-28 4:36 ` AKASHI Takahiro
2017-01-12 15:09 ` Mark Rutland
2017-01-12 15:09 ` Mark Rutland
2017-01-13 8:16 ` AKASHI Takahiro
2017-01-13 8:16 ` AKASHI Takahiro
2017-01-13 11:39 ` Mark Rutland
2017-01-13 11:39 ` Mark Rutland
2017-01-17 8:20 ` AKASHI Takahiro
2017-01-17 8:20 ` AKASHI Takahiro
2017-01-17 11:54 ` Mark Rutland
2017-01-17 11:54 ` Mark Rutland
2017-01-19 9:49 ` AKASHI Takahiro
2017-01-19 9:49 ` AKASHI Takahiro
2017-01-19 11:28 ` Mark Rutland
2017-01-19 11:28 ` Mark Rutland
2017-01-23 9:51 ` AKASHI Takahiro
2017-01-23 9:51 ` AKASHI Takahiro
2017-01-23 10:23 ` Mark Rutland
2017-01-23 10:23 ` Mark Rutland
2017-01-24 7:55 ` AKASHI Takahiro
2017-01-24 7:55 ` AKASHI Takahiro
2016-12-28 4:36 ` [PATCH v29 4/9] arm64: kdump: implement machine_crash_shutdown() AKASHI Takahiro
2016-12-28 4:36 ` AKASHI Takahiro
2017-01-10 11:32 ` Will Deacon
2017-01-10 11:32 ` Will Deacon
2017-01-11 6:36 ` AKASHI Takahiro
2017-01-11 6:36 ` AKASHI Takahiro
2017-01-11 10:54 ` Will Deacon
2017-01-11 10:54 ` Will Deacon
2017-01-12 4:21 ` AKASHI Takahiro
2017-01-12 4:21 ` AKASHI Takahiro
2017-01-12 12:01 ` Will Deacon
2017-01-12 12:01 ` Will Deacon
2017-01-23 17:46 ` Will Deacon
2017-01-23 17:46 ` Will Deacon
2017-01-24 7:52 ` AKASHI Takahiro
2017-01-24 7:52 ` AKASHI Takahiro
2016-12-28 4:36 ` [PATCH v29 5/9] arm64: kdump: add VMCOREINFO's for user-space tools AKASHI Takahiro
2016-12-28 4:36 ` AKASHI Takahiro
2016-12-28 4:36 ` [PATCH v29 6/9] arm64: kdump: provide /proc/vmcore file AKASHI Takahiro
2016-12-28 4:36 ` AKASHI Takahiro
2016-12-28 4:36 ` [PATCH v29 7/9] arm64: kdump: enable kdump in defconfig AKASHI Takahiro
2016-12-28 4:36 ` AKASHI Takahiro
2016-12-28 4:36 ` [PATCH v29 8/9] Documentation: kdump: describe arm64 port AKASHI Takahiro
2016-12-28 4:36 ` AKASHI Takahiro
2016-12-28 4:37 ` [PATCH v29 9/9] Documentation: dt: chosen properties for arm64 kdump AKASHI Takahiro
2016-12-28 4:37 ` AKASHI Takahiro
2016-12-28 4:37 ` AKASHI Takahiro
2017-01-10 11:10 ` Will Deacon
2017-01-10 11:10 ` Will Deacon
2017-01-10 11:10 ` Will Deacon
2017-01-12 15:39 ` Mark Rutland
2017-01-12 15:39 ` Mark Rutland
2017-01-12 15:39 ` Mark Rutland
2017-01-13 9:13 ` AKASHI Takahiro
2017-01-13 9:13 ` AKASHI Takahiro
2017-01-13 9:13 ` AKASHI Takahiro
2017-01-13 11:17 ` Mark Rutland
2017-01-13 11:17 ` Mark Rutland
2017-01-13 11:17 ` Mark Rutland
2017-01-16 8:25 ` AKASHI Takahiro
2017-01-16 8:25 ` AKASHI Takahiro
2017-01-16 8:25 ` AKASHI Takahiro
2017-01-17 8:26 ` Dave Young
2017-01-17 8:26 ` Dave Young
2017-01-17 8:26 ` Dave Young
2017-01-19 9:01 ` AKASHI Takahiro
2017-01-19 9:01 ` AKASHI Takahiro
2017-01-19 9:01 ` AKASHI Takahiro
2017-01-17 11:13 ` Mark Rutland
2017-01-17 11:13 ` Mark Rutland
2017-01-17 11:13 ` Mark Rutland
2017-01-06 3:26 ` [PATCH v29 0/9] arm64: add kdump support Pratyush Anand
2017-01-06 3:26 ` Pratyush Anand
2017-01-06 4:34 ` AKASHI Takahiro
2017-01-06 4:34 ` AKASHI Takahiro
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=20170111015737.GA518@arm.com \
--to=dennis.chen@arm.com \
--cc=akpm@linux-foundation.org \
--cc=bauerman@linux.vnet.ibm.com \
--cc=catalin.marinas@arm.com \
--cc=dyoung@redhat.com \
--cc=geoff@infradead.org \
--cc=james.morse@arm.com \
--cc=kexec@lists.infradead.org \
--cc=kuleshovmail@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mm@kvack.org \
--cc=mark.rutland@arm.com \
--cc=nd@arm.com \
--cc=takahiro.akashi@linaro.org \
--cc=tj@kernel.org \
--cc=will.deacon@arm.com \
--cc=zijun_hu@htc.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.