All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@linux.ibm.com>
To: Sam Ravnborg <sam@ravnborg.org>
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:49:21 +0000	[thread overview]
Message-ID: <20181203164920.GB26700@rapoport-lnx> (raw)
In-Reply-To: <20181203162908.GB4244@ravnborg.org>

On Mon, Dec 03, 2018 at 05:29:08PM +0100, Sam Ravnborg wrote:
> 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?

memblock_phys_alloc_try_nid() also calls panic if an allocation fails. So
in either case we never reach prom_halt() code.

Actually, sparc is rather an exception from the general practice to rely on
panic() inside the early allocator rather than to check the return value.
 
> 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.

I really tried to be careful and did the replacements only for the calls
that do panic if an allocation fails.
 
> 	Sam
> 

-- 
Sincerely yours,
Mike.

WARNING: multiple messages have this Message-ID (diff)
From: Mike Rapoport <rppt@linux.ibm.com>
To: Sam Ravnborg <sam@ravnborg.org>
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 18:49:21 +0200	[thread overview]
Message-ID: <20181203164920.GB26700@rapoport-lnx> (raw)
In-Reply-To: <20181203162908.GB4244@ravnborg.org>

On Mon, Dec 03, 2018 at 05:29:08PM +0100, Sam Ravnborg wrote:
> 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?

memblock_phys_alloc_try_nid() also calls panic if an allocation fails. So
in either case we never reach prom_halt() code.

Actually, sparc is rather an exception from the general practice to rely on
panic() inside the early allocator rather than to check the return value.
 
> 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.

I really tried to be careful and did the replacements only for the calls
that do panic if an allocation fails.
 
> 	Sam
> 

-- 
Sincerely yours,
Mike.


WARNING: multiple messages have this Message-ID (diff)
From: Mike Rapoport <rppt@linux.ibm.com>
To: Sam Ravnborg <sam@ravnborg.org>
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 18:49:21 +0200	[thread overview]
Message-ID: <20181203164920.GB26700@rapoport-lnx> (raw)
In-Reply-To: <20181203162908.GB4244@ravnborg.org>

On Mon, Dec 03, 2018 at 05:29:08PM +0100, Sam Ravnborg wrote:
> 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?

memblock_phys_alloc_try_nid() also calls panic if an allocation fails. So
in either case we never reach prom_halt() code.

Actually, sparc is rather an exception from the general practice to rely on
panic() inside the early allocator rather than to check the return value.
 
> 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.

I really tried to be careful and did the replacements only for the calls
that do panic if an allocation fails.
 
> 	Sam
> 

-- 
Sincerely yours,
Mike.


WARNING: multiple messages have this Message-ID (diff)
From: Mike Rapoport <rppt@linux.ibm.com>
To: Sam Ravnborg <sam@ravnborg.org>
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 18:49:21 +0200	[thread overview]
Message-ID: <20181203164920.GB26700@rapoport-lnx> (raw)
In-Reply-To: <20181203162908.GB4244@ravnborg.org>

On Mon, Dec 03, 2018 at 05:29:08PM +0100, Sam Ravnborg wrote:
> 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?

memblock_phys_alloc_try_nid() also calls panic if an allocation fails. So
in either case we never reach prom_halt() code.

Actually, sparc is rather an exception from the general practice to rely on
panic() inside the early allocator rather than to check the return value.
 
> 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.

I really tried to be careful and did the replacements only for the calls
that do panic if an allocation fails.
 
> 	Sam
> 

-- 
Sincerely yours,
Mike.


_______________________________________________
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: Mike Rapoport <rppt@linux.ibm.com>
To: openrisc@lists.librecores.org
Subject: [OpenRISC] [PATCH v2 5/6] arch: simplify several early memory allocations
Date: Mon, 3 Dec 2018 18:49:21 +0200	[thread overview]
Message-ID: <20181203164920.GB26700@rapoport-lnx> (raw)
In-Reply-To: <20181203162908.GB4244@ravnborg.org>

On Mon, Dec 03, 2018 at 05:29:08PM +0100, Sam Ravnborg wrote:
> 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?

memblock_phys_alloc_try_nid() also calls panic if an allocation fails. So
in either case we never reach prom_halt() code.

Actually, sparc is rather an exception from the general practice to rely on
panic() inside the early allocator rather than to check the return value.
 
> 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.

I really tried to be careful and did the replacements only for the calls
that do panic if an allocation fails.
 
> 	Sam
> 

-- 
Sincerely yours,
Mike.


  reply	other threads:[~2018-12-03 16:49 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 ` [OpenRISC] " 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 ` [PATCH v2 1/6] powerpc: prefer memblock APIs returning virtual address Mike Rapoport
2018-12-03 15:47   ` [OpenRISC] " 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-04  9:59   ` Michael Ellerman
2018-12-04  9:59     ` [OpenRISC] " 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 17:13     ` Mike Rapoport
2018-12-04 17:13       ` [OpenRISC] " 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-05 12:37       ` Michael Ellerman
2018-12-05 12:37         ` [OpenRISC] " 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 21:22         ` Mike Rapoport
2018-12-05 21:22           ` [OpenRISC] " 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-03 15:47 ` [PATCH v2 2/6] microblaze: prefer memblock API " Mike Rapoport
2018-12-03 15:47   ` [OpenRISC] " 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-05 15:29   ` Michal Simek
2018-12-05 15:29     ` [OpenRISC] " 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-06  7:31     ` Mike Rapoport
2018-12-06  7:31       ` [OpenRISC] " 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-03 15:47 ` [PATCH v2 3/6] sh: prefer memblock APIs " Mike Rapoport
2018-12-03 15:47   ` [OpenRISC] " 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 16:10   ` Sam Ravnborg
2018-12-03 16:10     ` [OpenRISC] " 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:28     ` Mike Rapoport
2018-12-03 16:28       ` [OpenRISC] " 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 15:47 ` [PATCH v2 4/6] openrisc: simplify pte_alloc_one_kernel() Mike Rapoport
2018-12-03 15:47   ` [OpenRISC] " 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 ` [PATCH v2 5/6] arch: simplify several early memory allocations Mike Rapoport
2018-12-03 15:47   ` [OpenRISC] " 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 16:29   ` Sam Ravnborg
2018-12-03 16:29     ` [OpenRISC] " Sam Ravnborg
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:49     ` Mike Rapoport [this message]
2018-12-03 16:49       ` [OpenRISC] " 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-06 18:08       ` Sam Ravnborg
2018-12-06 18:08         ` [OpenRISC] " 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 21:30         ` Mike Rapoport
2018-12-06 21:30           ` [OpenRISC] " 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-03 15:47 ` [PATCH v2 6/6] arm, unicore32: remove early_alloc*() wrappers Mike Rapoport
2018-12-03 15:47   ` [OpenRISC] " 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 16:27   ` Rob Herring
2018-12-03 16:27     ` [OpenRISC] " 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:55     ` Mike Rapoport
2018-12-03 16:55       ` [OpenRISC] " Mike Rapoport
2018-12-03 16:55       ` Mike Rapoport
2018-12-03 16:55       ` Mike Rapoport
2018-12-03 16:55       ` 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=20181203164920.GB26700@rapoport-lnx \
    --to=rppt@linux.ibm.com \
    --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=sam@ravnborg.org \
    --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.