All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.