From: Sam Ravnborg <sam@ravnborg.org>
To: Mike Rapoport <rppt@linux.ibm.com>
Cc: Michal Hocko <mhocko@suse.com>,
linux-sh@vger.kernel.org,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
linux-mm@kvack.org, Rich Felker <dalias@libc.org>,
Paul Mackerras <paulus@samba.org>,
sparclinux@vger.kernel.org, Vincent Chen <deanbo422@gmail.com>,
Jonas Bonn <jonas@southpole.se>,
linux-c6x-dev@linux-c6x.org,
Yoshinori Sato <ysato@users.sourceforge.jp>,
Michael Ellerman <mpe@ellerman.id.au>,
Russell King <linux@armlinux.org.uk>,
Mark Salter <msalter@redhat.com>, Arnd Bergmann <arnd@arndb.de>,
Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>,
openrisc@lists.librecores.org, Greentime Hu <green.hu@gmail.com>,
Stafford Horne <shorne@gmail.com>, Guan Xuetao <gxt@pku.edu.cn>,
linux-arm-kernel@lists.infradead.org,
Michal Simek <monstr@monstr.eu>,
linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
linuxppc-dev@lists.ozlabs.org,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH v2 5/6] arch: simplify several early memory allocations
Date: Mon, 03 Dec 2018 16:29:08 +0000 [thread overview]
Message-ID: <20181203162908.GB4244@ravnborg.org> (raw)
In-Reply-To: <1543852035-26634-6-git-send-email-rppt@linux.ibm.com>
Hi Mike.
> index c37955d..2a17665 100644
> --- a/arch/sparc/kernel/prom_64.c
> +++ b/arch/sparc/kernel/prom_64.c
> @@ -34,16 +34,13 @@
>
> void * __init prom_early_alloc(unsigned long size)
> {
> - unsigned long paddr = memblock_phys_alloc(size, SMP_CACHE_BYTES);
> - void *ret;
> + void *ret = memblock_alloc(size, SMP_CACHE_BYTES);
>
> - if (!paddr) {
> + if (!ret) {
> prom_printf("prom_early_alloc(%lu) failed\n", size);
> prom_halt();
> }
>
> - ret = __va(paddr);
> - memset(ret, 0, size);
> prom_early_allocated += size;
>
> return ret;
memblock_alloc() calls memblock_alloc_try_nid().
And if allocation fails then memblock_alloc_try_nid() calls panic().
So will we ever hit the prom_halt() code?
Do we have a panic() implementation that actually returns?
> diff --git a/arch/sparc/mm/init_64.c b/arch/sparc/mm/init_64.c
> index 3c8aac2..52884f4 100644
> --- a/arch/sparc/mm/init_64.c
> +++ b/arch/sparc/mm/init_64.c
> @@ -1089,16 +1089,13 @@ static void __init allocate_node_data(int nid)
> struct pglist_data *p;
> unsigned long start_pfn, end_pfn;
> #ifdef CONFIG_NEED_MULTIPLE_NODES
> - unsigned long paddr;
>
> - paddr = memblock_phys_alloc_try_nid(sizeof(struct pglist_data),
> - SMP_CACHE_BYTES, nid);
> - if (!paddr) {
> + NODE_DATA(nid) = memblock_alloc_node(sizeof(struct pglist_data),
> + SMP_CACHE_BYTES, nid);
> + if (!NODE_DATA(nid)) {
> prom_printf("Cannot allocate pglist_data for nid[%d]\n", nid);
> prom_halt();
> }
> - NODE_DATA(nid) = __va(paddr);
> - memset(NODE_DATA(nid), 0, sizeof(struct pglist_data));
>
> NODE_DATA(nid)->node_id = nid;
> #endif
Same here.
I did not look at the other cases.
Sam
WARNING: multiple messages have this Message-ID (diff)
From: Sam Ravnborg <sam@ravnborg.org>
To: openrisc@lists.librecores.org
Subject: [OpenRISC] [PATCH v2 5/6] arch: simplify several early memory allocations
Date: Mon, 3 Dec 2018 17:29:08 +0100 [thread overview]
Message-ID: <20181203162908.GB4244@ravnborg.org> (raw)
In-Reply-To: <1543852035-26634-6-git-send-email-rppt@linux.ibm.com>
Hi Mike.
> index c37955d..2a17665 100644
> --- a/arch/sparc/kernel/prom_64.c
> +++ b/arch/sparc/kernel/prom_64.c
> @@ -34,16 +34,13 @@
>
> void * __init prom_early_alloc(unsigned long size)
> {
> - unsigned long paddr = memblock_phys_alloc(size, SMP_CACHE_BYTES);
> - void *ret;
> + void *ret = memblock_alloc(size, SMP_CACHE_BYTES);
>
> - if (!paddr) {
> + if (!ret) {
> prom_printf("prom_early_alloc(%lu) failed\n", size);
> prom_halt();
> }
>
> - ret = __va(paddr);
> - memset(ret, 0, size);
> prom_early_allocated += size;
>
> return ret;
memblock_alloc() calls memblock_alloc_try_nid().
And if allocation fails then memblock_alloc_try_nid() calls panic().
So will we ever hit the prom_halt() code?
Do we have a panic() implementation that actually returns?
> diff --git a/arch/sparc/mm/init_64.c b/arch/sparc/mm/init_64.c
> index 3c8aac2..52884f4 100644
> --- a/arch/sparc/mm/init_64.c
> +++ b/arch/sparc/mm/init_64.c
> @@ -1089,16 +1089,13 @@ static void __init allocate_node_data(int nid)
> struct pglist_data *p;
> unsigned long start_pfn, end_pfn;
> #ifdef CONFIG_NEED_MULTIPLE_NODES
> - unsigned long paddr;
>
> - paddr = memblock_phys_alloc_try_nid(sizeof(struct pglist_data),
> - SMP_CACHE_BYTES, nid);
> - if (!paddr) {
> + NODE_DATA(nid) = memblock_alloc_node(sizeof(struct pglist_data),
> + SMP_CACHE_BYTES, nid);
> + if (!NODE_DATA(nid)) {
> prom_printf("Cannot allocate pglist_data for nid[%d]\n", nid);
> prom_halt();
> }
> - NODE_DATA(nid) = __va(paddr);
> - memset(NODE_DATA(nid), 0, sizeof(struct pglist_data));
>
> NODE_DATA(nid)->node_id = nid;
> #endif
Same here.
I did not look at the other cases.
Sam
WARNING: multiple messages have this Message-ID (diff)
From: Sam Ravnborg <sam@ravnborg.org>
To: Mike Rapoport <rppt@linux.ibm.com>
Cc: Michal Hocko <mhocko@suse.com>,
linux-sh@vger.kernel.org, linux-mm@kvack.org,
Rich Felker <dalias@libc.org>, Paul Mackerras <paulus@samba.org>,
sparclinux@vger.kernel.org, Vincent Chen <deanbo422@gmail.com>,
Jonas Bonn <jonas@southpole.se>,
linux-c6x-dev@linux-c6x.org,
Yoshinori Sato <ysato@users.sourceforge.jp>,
Russell King <linux@armlinux.org.uk>,
Mark Salter <msalter@redhat.com>, Arnd Bergmann <arnd@arndb.de>,
Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>,
openrisc@lists.librecores.org, Greentime Hu <green.hu@gmail.com>,
Stafford Horne <shorne@gmail.com>, Guan Xuetao <gxt@pku.edu.cn>,
linux-arm-kernel@lists.infradead.org,
Michal Simek <monstr@monstr.eu>,
linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
linuxppc-dev@lists.ozlabs.org,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH v2 5/6] arch: simplify several early memory allocations
Date: Mon, 3 Dec 2018 17:29:08 +0100 [thread overview]
Message-ID: <20181203162908.GB4244@ravnborg.org> (raw)
In-Reply-To: <1543852035-26634-6-git-send-email-rppt@linux.ibm.com>
Hi Mike.
> index c37955d..2a17665 100644
> --- a/arch/sparc/kernel/prom_64.c
> +++ b/arch/sparc/kernel/prom_64.c
> @@ -34,16 +34,13 @@
>
> void * __init prom_early_alloc(unsigned long size)
> {
> - unsigned long paddr = memblock_phys_alloc(size, SMP_CACHE_BYTES);
> - void *ret;
> + void *ret = memblock_alloc(size, SMP_CACHE_BYTES);
>
> - if (!paddr) {
> + if (!ret) {
> prom_printf("prom_early_alloc(%lu) failed\n", size);
> prom_halt();
> }
>
> - ret = __va(paddr);
> - memset(ret, 0, size);
> prom_early_allocated += size;
>
> return ret;
memblock_alloc() calls memblock_alloc_try_nid().
And if allocation fails then memblock_alloc_try_nid() calls panic().
So will we ever hit the prom_halt() code?
Do we have a panic() implementation that actually returns?
> diff --git a/arch/sparc/mm/init_64.c b/arch/sparc/mm/init_64.c
> index 3c8aac2..52884f4 100644
> --- a/arch/sparc/mm/init_64.c
> +++ b/arch/sparc/mm/init_64.c
> @@ -1089,16 +1089,13 @@ static void __init allocate_node_data(int nid)
> struct pglist_data *p;
> unsigned long start_pfn, end_pfn;
> #ifdef CONFIG_NEED_MULTIPLE_NODES
> - unsigned long paddr;
>
> - paddr = memblock_phys_alloc_try_nid(sizeof(struct pglist_data),
> - SMP_CACHE_BYTES, nid);
> - if (!paddr) {
> + NODE_DATA(nid) = memblock_alloc_node(sizeof(struct pglist_data),
> + SMP_CACHE_BYTES, nid);
> + if (!NODE_DATA(nid)) {
> prom_printf("Cannot allocate pglist_data for nid[%d]\n", nid);
> prom_halt();
> }
> - NODE_DATA(nid) = __va(paddr);
> - memset(NODE_DATA(nid), 0, sizeof(struct pglist_data));
>
> NODE_DATA(nid)->node_id = nid;
> #endif
Same here.
I did not look at the other cases.
Sam
WARNING: multiple messages have this Message-ID (diff)
From: Sam Ravnborg <sam@ravnborg.org>
To: Mike Rapoport <rppt@linux.ibm.com>
Cc: Michal Hocko <mhocko@suse.com>,
linux-sh@vger.kernel.org,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
linux-mm@kvack.org, Rich Felker <dalias@libc.org>,
Paul Mackerras <paulus@samba.org>,
sparclinux@vger.kernel.org, Vincent Chen <deanbo422@gmail.com>,
Jonas Bonn <jonas@southpole.se>,
linux-c6x-dev@linux-c6x.org,
Yoshinori Sato <ysato@users.sourceforge.jp>,
Michael Ellerman <mpe@ellerman.id.au>,
Russell King <linux@armlinux.org.uk>,
Mark Salter <msalter@redhat.com>, Arnd Bergmann <arnd@arndb.de>,
Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>,
openrisc@lists.librecores.org, Greentime Hu <green.hu@gmail.com>,
Stafford Horne <shorne@gmail.com>, Guan Xuetao <gxt@pku.edu.cn>,
linux-arm-kernel@lists.infradead.org,
Michal Simek <monstr@monstr.eu>,
linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
linuxppc-dev@lists.ozlabs.org,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH v2 5/6] arch: simplify several early memory allocations
Date: Mon, 3 Dec 2018 17:29:08 +0100 [thread overview]
Message-ID: <20181203162908.GB4244@ravnborg.org> (raw)
In-Reply-To: <1543852035-26634-6-git-send-email-rppt@linux.ibm.com>
Hi Mike.
> index c37955d..2a17665 100644
> --- a/arch/sparc/kernel/prom_64.c
> +++ b/arch/sparc/kernel/prom_64.c
> @@ -34,16 +34,13 @@
>
> void * __init prom_early_alloc(unsigned long size)
> {
> - unsigned long paddr = memblock_phys_alloc(size, SMP_CACHE_BYTES);
> - void *ret;
> + void *ret = memblock_alloc(size, SMP_CACHE_BYTES);
>
> - if (!paddr) {
> + if (!ret) {
> prom_printf("prom_early_alloc(%lu) failed\n", size);
> prom_halt();
> }
>
> - ret = __va(paddr);
> - memset(ret, 0, size);
> prom_early_allocated += size;
>
> return ret;
memblock_alloc() calls memblock_alloc_try_nid().
And if allocation fails then memblock_alloc_try_nid() calls panic().
So will we ever hit the prom_halt() code?
Do we have a panic() implementation that actually returns?
> diff --git a/arch/sparc/mm/init_64.c b/arch/sparc/mm/init_64.c
> index 3c8aac2..52884f4 100644
> --- a/arch/sparc/mm/init_64.c
> +++ b/arch/sparc/mm/init_64.c
> @@ -1089,16 +1089,13 @@ static void __init allocate_node_data(int nid)
> struct pglist_data *p;
> unsigned long start_pfn, end_pfn;
> #ifdef CONFIG_NEED_MULTIPLE_NODES
> - unsigned long paddr;
>
> - paddr = memblock_phys_alloc_try_nid(sizeof(struct pglist_data),
> - SMP_CACHE_BYTES, nid);
> - if (!paddr) {
> + NODE_DATA(nid) = memblock_alloc_node(sizeof(struct pglist_data),
> + SMP_CACHE_BYTES, nid);
> + if (!NODE_DATA(nid)) {
> prom_printf("Cannot allocate pglist_data for nid[%d]\n", nid);
> prom_halt();
> }
> - NODE_DATA(nid) = __va(paddr);
> - memset(NODE_DATA(nid), 0, sizeof(struct pglist_data));
>
> NODE_DATA(nid)->node_id = nid;
> #endif
Same here.
I did not look at the other cases.
Sam
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Sam Ravnborg <sam@ravnborg.org>
To: Mike Rapoport <rppt@linux.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Arnd Bergmann <arnd@arndb.de>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
"David S. Miller" <davem@davemloft.net>,
Guan Xuetao <gxt@pku.edu.cn>, Greentime Hu <green.hu@gmail.com>,
Jonas Bonn <jonas@southpole.se>,
Michael Ellerman <mpe@ellerman.id.au>,
Michal Hocko <mhocko@suse.com>, Michal Simek <monstr@monstr.eu>,
Mark Salter <msalter@redhat.com>,
Paul Mackerras <paulus@samba.org>, Rich Felker <dalias@libc.org>,
Russell King <linux@armlinux.org.uk>,
Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>,
Stafford Horne <shorne@gmail.com>,
Vincent Chen <deanbo422@gmail.com>,
Yoshinori Sato <ysato@users.sourceforge.jp>,
linux-arm-kernel@lists.infradead.org,
linux-c6x-dev@linux-c6x.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, linux-sh@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, openrisc@lists.librecores.org,
sparclinux@vger.kernel.org
Subject: Re: [PATCH v2 5/6] arch: simplify several early memory allocations
Date: Mon, 3 Dec 2018 17:29:08 +0100 [thread overview]
Message-ID: <20181203162908.GB4244@ravnborg.org> (raw)
In-Reply-To: <1543852035-26634-6-git-send-email-rppt@linux.ibm.com>
Hi Mike.
> index c37955d..2a17665 100644
> --- a/arch/sparc/kernel/prom_64.c
> +++ b/arch/sparc/kernel/prom_64.c
> @@ -34,16 +34,13 @@
>
> void * __init prom_early_alloc(unsigned long size)
> {
> - unsigned long paddr = memblock_phys_alloc(size, SMP_CACHE_BYTES);
> - void *ret;
> + void *ret = memblock_alloc(size, SMP_CACHE_BYTES);
>
> - if (!paddr) {
> + if (!ret) {
> prom_printf("prom_early_alloc(%lu) failed\n", size);
> prom_halt();
> }
>
> - ret = __va(paddr);
> - memset(ret, 0, size);
> prom_early_allocated += size;
>
> return ret;
memblock_alloc() calls memblock_alloc_try_nid().
And if allocation fails then memblock_alloc_try_nid() calls panic().
So will we ever hit the prom_halt() code?
Do we have a panic() implementation that actually returns?
> diff --git a/arch/sparc/mm/init_64.c b/arch/sparc/mm/init_64.c
> index 3c8aac2..52884f4 100644
> --- a/arch/sparc/mm/init_64.c
> +++ b/arch/sparc/mm/init_64.c
> @@ -1089,16 +1089,13 @@ static void __init allocate_node_data(int nid)
> struct pglist_data *p;
> unsigned long start_pfn, end_pfn;
> #ifdef CONFIG_NEED_MULTIPLE_NODES
> - unsigned long paddr;
>
> - paddr = memblock_phys_alloc_try_nid(sizeof(struct pglist_data),
> - SMP_CACHE_BYTES, nid);
> - if (!paddr) {
> + NODE_DATA(nid) = memblock_alloc_node(sizeof(struct pglist_data),
> + SMP_CACHE_BYTES, nid);
> + if (!NODE_DATA(nid)) {
> prom_printf("Cannot allocate pglist_data for nid[%d]\n", nid);
> prom_halt();
> }
> - NODE_DATA(nid) = __va(paddr);
> - memset(NODE_DATA(nid), 0, sizeof(struct pglist_data));
>
> NODE_DATA(nid)->node_id = nid;
> #endif
Same here.
I did not look at the other cases.
Sam
next prev parent reply other threads:[~2018-12-03 16:29 UTC|newest]
Thread overview: 106+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-03 15:47 [PATCH v2 0/6] memblock: simplify several early memory allocation Mike Rapoport
2018-12-03 15:47 ` Mike Rapoport
2018-12-03 15:47 ` Mike Rapoport
2018-12-03 15:47 ` Mike Rapoport
2018-12-03 15:47 ` [OpenRISC] " Mike Rapoport
2018-12-03 15:47 ` [PATCH v2 1/6] powerpc: prefer memblock APIs returning virtual address Mike Rapoport
2018-12-03 15:47 ` Mike Rapoport
2018-12-03 15:47 ` Mike Rapoport
2018-12-03 15:47 ` Mike Rapoport
2018-12-03 15:47 ` [OpenRISC] " Mike Rapoport
2018-12-04 9:59 ` Michael Ellerman
2018-12-04 9:59 ` Michael Ellerman
2018-12-04 9:59 ` Michael Ellerman
2018-12-04 9:59 ` Michael Ellerman
2018-12-04 9:59 ` Michael Ellerman
2018-12-04 9:59 ` [OpenRISC] " Michael Ellerman
2018-12-04 17:13 ` Mike Rapoport
2018-12-04 17:13 ` Mike Rapoport
2018-12-04 17:13 ` Mike Rapoport
2018-12-04 17:13 ` Mike Rapoport
2018-12-04 17:13 ` [OpenRISC] " Mike Rapoport
2018-12-05 12:37 ` Michael Ellerman
2018-12-05 12:37 ` Michael Ellerman
2018-12-05 12:37 ` Michael Ellerman
2018-12-05 12:37 ` Michael Ellerman
2018-12-05 12:37 ` [OpenRISC] " Michael Ellerman
2018-12-05 21:22 ` Mike Rapoport
2018-12-05 21:22 ` Mike Rapoport
2018-12-05 21:22 ` Mike Rapoport
2018-12-05 21:22 ` Mike Rapoport
2018-12-05 21:22 ` [OpenRISC] " Mike Rapoport
2018-12-03 15:47 ` [PATCH v2 2/6] microblaze: prefer memblock API " Mike Rapoport
2018-12-03 15:47 ` Mike Rapoport
2018-12-03 15:47 ` Mike Rapoport
2018-12-03 15:47 ` Mike Rapoport
2018-12-03 15:47 ` [OpenRISC] " Mike Rapoport
2018-12-05 15:29 ` Michal Simek
2018-12-05 15:29 ` Michal Simek
2018-12-05 15:29 ` Michal Simek
2018-12-05 15:29 ` Michal Simek
2018-12-05 15:29 ` [OpenRISC] " Michal Simek
2018-12-06 7:31 ` Mike Rapoport
2018-12-06 7:31 ` Mike Rapoport
2018-12-06 7:31 ` Mike Rapoport
2018-12-06 7:31 ` Mike Rapoport
2018-12-06 7:31 ` [OpenRISC] " Mike Rapoport
2018-12-03 15:47 ` [PATCH v2 3/6] sh: prefer memblock APIs " Mike Rapoport
2018-12-03 15:47 ` Mike Rapoport
2018-12-03 15:47 ` Mike Rapoport
2018-12-03 15:47 ` Mike Rapoport
2018-12-03 15:47 ` [OpenRISC] " Mike Rapoport
2018-12-03 16:10 ` Sam Ravnborg
2018-12-03 16:10 ` Sam Ravnborg
2018-12-03 16:10 ` Sam Ravnborg
2018-12-03 16:10 ` Sam Ravnborg
2018-12-03 16:10 ` [OpenRISC] " Sam Ravnborg
2018-12-03 16:28 ` Mike Rapoport
2018-12-03 16:28 ` Mike Rapoport
2018-12-03 16:28 ` Mike Rapoport
2018-12-03 16:28 ` Mike Rapoport
2018-12-03 16:28 ` [OpenRISC] " Mike Rapoport
2018-12-03 15:47 ` [PATCH v2 4/6] openrisc: simplify pte_alloc_one_kernel() Mike Rapoport
2018-12-03 15:47 ` Mike Rapoport
2018-12-03 15:47 ` Mike Rapoport
2018-12-03 15:47 ` Mike Rapoport
2018-12-03 15:47 ` [OpenRISC] " Mike Rapoport
2018-12-03 15:47 ` [PATCH v2 5/6] arch: simplify several early memory allocations Mike Rapoport
2018-12-03 15:47 ` Mike Rapoport
2018-12-03 15:47 ` Mike Rapoport
2018-12-03 15:47 ` Mike Rapoport
2018-12-03 15:47 ` [OpenRISC] " Mike Rapoport
2018-12-03 16:29 ` Sam Ravnborg [this message]
2018-12-03 16:29 ` Sam Ravnborg
2018-12-03 16:29 ` Sam Ravnborg
2018-12-03 16:29 ` Sam Ravnborg
2018-12-03 16:29 ` [OpenRISC] " Sam Ravnborg
2018-12-03 16:49 ` Mike Rapoport
2018-12-03 16:49 ` Mike Rapoport
2018-12-03 16:49 ` Mike Rapoport
2018-12-03 16:49 ` Mike Rapoport
2018-12-03 16:49 ` [OpenRISC] " Mike Rapoport
2018-12-06 18:08 ` Sam Ravnborg
2018-12-06 18:08 ` Sam Ravnborg
2018-12-06 18:08 ` Sam Ravnborg
2018-12-06 18:08 ` Sam Ravnborg
2018-12-06 18:08 ` [OpenRISC] " Sam Ravnborg
2018-12-06 21:30 ` Mike Rapoport
2018-12-06 21:30 ` Mike Rapoport
2018-12-06 21:30 ` Mike Rapoport
2018-12-06 21:30 ` Mike Rapoport
2018-12-06 21:30 ` [OpenRISC] " Mike Rapoport
2018-12-03 15:47 ` [PATCH v2 6/6] arm, unicore32: remove early_alloc*() wrappers Mike Rapoport
2018-12-03 15:47 ` Mike Rapoport
2018-12-03 15:47 ` Mike Rapoport
2018-12-03 15:47 ` Mike Rapoport
2018-12-03 15:47 ` [OpenRISC] " Mike Rapoport
2018-12-03 16:27 ` Rob Herring
2018-12-03 16:27 ` Rob Herring
2018-12-03 16:27 ` Rob Herring
2018-12-03 16:27 ` Rob Herring
2018-12-03 16:27 ` [OpenRISC] " Rob Herring
2018-12-03 16:55 ` Mike Rapoport
2018-12-03 16:55 ` Mike Rapoport
2018-12-03 16:55 ` Mike Rapoport
2018-12-03 16:55 ` Mike Rapoport
2018-12-03 16:55 ` [OpenRISC] " Mike Rapoport
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=20181203162908.GB4244@ravnborg.org \
--to=sam@ravnborg.org \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=benh@kernel.crashing.org \
--cc=dalias@libc.org \
--cc=davem@davemloft.net \
--cc=deanbo422@gmail.com \
--cc=green.hu@gmail.com \
--cc=gxt@pku.edu.cn \
--cc=jonas@southpole.se \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-c6x-dev@linux-c6x.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mhocko@suse.com \
--cc=monstr@monstr.eu \
--cc=mpe@ellerman.id.au \
--cc=msalter@redhat.com \
--cc=openrisc@lists.librecores.org \
--cc=paulus@samba.org \
--cc=rppt@linux.ibm.com \
--cc=shorne@gmail.com \
--cc=sparclinux@vger.kernel.org \
--cc=stefan.kristiansson@saunalahti.fi \
--cc=ysato@users.sourceforge.jp \
/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.