Re: [PATCH 5/5] arch: simplify several early memory allocations

2018-11-25 Thread Mike Rapoport
On Mon, Nov 26, 2018 at 08:03:55AM +0100, Christophe LEROY wrote: > > > Le 25/11/2018 à 22:44, Mike Rapoport a écrit : > >There are several early memory allocations in arch/ code that use > >memblock_phys_alloc() to allocate memory, convert the returned physical > >address to the virtual address

Re: [PATCH 5/5] arch: simplify several early memory allocations

2018-11-25 Thread Christophe LEROY
Le 25/11/2018 à 22:44, Mike Rapoport a écrit : There are several early memory allocations in arch/ code that use memblock_phys_alloc() to allocate memory, convert the returned physical address to the virtual address and then set the allocated memory to zero. Exactly the same behaviour can be

Re: New linux-next KCFLAGS

2018-11-25 Thread Stephen Rothwell
Hi Kees, On Mon, 26 Nov 2018 17:49:26 +1100 Stephen Rothwell wrote: > > On Sun, 25 Nov 2018 21:46:20 -0800 Kees Cook wrote: > > > > Excellent! (Though, wait, does this mean everyone _else_ will see this > > too? I'm worried that will be way too noisy...) > > Ah, yes, you may be right.

Re: [PATCH] powerpc/kernel: Remove gcc 4 workaround from include/asm/io.h

2018-11-25 Thread Christophe LEROY
Le 25/11/2018 à 22:14, Darren Stevens a écrit : There are verions of DEF_MMIO_IN_X and DEF_MMIO_OUT_X in asm/io.h that contain a workaround for a limitation in gcc <=4.0, but the minimum supported version of gcc is now 4.6, so these can be safely removed. This code is already gone, see

Re: New linux-next KCFLAGS

2018-11-25 Thread Stephen Rothwell
Hi Kees, On Sun, 25 Nov 2018 21:46:20 -0800 Kees Cook wrote: > > Excellent! (Though, wait, does this mean everyone _else_ will see this > too? I'm worried that will be way too noisy...) Ah, yes, you may be right. everyone will see them :-( I may have to figure out another way to do this for

Re: [PATCH] mm: Replace all open encodings for NUMA_NO_NODE

2018-11-25 Thread Anshuman Khandual
On 11/24/2018 07:35 PM, Vinod Koul wrote: > On 23-11-18, 15:24, Anshuman Khandual wrote: > >> --- a/drivers/dma/dmaengine.c >> +++ b/drivers/dma/dmaengine.c >> @@ -386,7 +386,8 @@ EXPORT_SYMBOL(dma_issue_pending_all); >> static bool dma_chan_is_local(struct dma_chan *chan, int cpu) >> { >>

Re: [PATCH v2] cpufreq: pmac64: add of_node_put()

2018-11-25 Thread Viresh Kumar
On 23-11-18, 08:33, Yangtao Li wrote: > of_find_node_by_path() acquires a reference to the node > returned by it and that reference needs to be dropped by its caller. > g5_neo2_cpufreq_init() doesn't do that, so fix it. > > Signed-off-by: Yangtao Li > Acked-by: Viresh Kumar > --- > Changes in

[PATCH 3/3] powerpc/smp: __smp_send_nmi_ipi static

2018-11-25 Thread Nicholas Piggin
Signed-off-by: Nicholas Piggin --- arch/powerpc/kernel/smp.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c index 6e521a3f67ca..5366d9e7bed4 100644 --- a/arch/powerpc/kernel/smp.c +++ b/arch/powerpc/kernel/smp.c @@

[PATCH 2/3] powerpc/smp: Fix NMI IPI xmon timeout

2018-11-25 Thread Nicholas Piggin
The xmon debugger IPI handler waits in the callback function while xmon is still active. This means they don't complete the IPI, and the initiator always times out waiting for them. Things manage to work after the timeout because there is some fallback logic to keep NMI IPI state sane in case of

[PATCH 1/3] powerpc/smp: Fix NMI IPI timeout

2018-11-25 Thread Nicholas Piggin
The NMI IPI timeout logic is broken, if __smp_send_nmi_ipi times out on the first condition, delay_us will be zero which will send it into the second spin loop with no timeout so it will spin forever. Fixes: 5b73151fff63 ("powerpc: NMI IPI make NMI IPIs fully sychronous") Signed-off-by: Nicholas

[PATCH 0/3] Fix NMI IPI timeouts

2018-11-25 Thread Nicholas Piggin
The first two patches fix timeouts and deadlocks using NMI IPIs. The xmon deadlock fails with a timeout so it wasn't really noticed. The infinite timeout only hits when the system is in really bad shape or the sreset handler is broken somehow (e.g., running a guest and no KVM test in the handler).

[PATCH] powerpc/mm: Fix linux page tables build with some configs

2018-11-25 Thread Michael Ellerman
For some configs the build fails with: arch/powerpc/mm/dump_linuxpagetables.c: In function 'populate_markers': arch/powerpc/mm/dump_linuxpagetables.c:306:39: error: 'PKMAP_BASE' undeclared (first use in this function) arch/powerpc/mm/dump_linuxpagetables.c:314:50: error: 'LAST_PKMAP'

Re: [PATCH 1/2 v3] powerpc/fsl: Use new clockgen binding

2018-11-25 Thread Scott Wood
On Wed, 2018-10-31 at 14:57 +0800, Yuantian Tang wrote: > From: Scott Wood > > The driver retains compatibility with old device trees, but we don't > want the old nodes lying around to be copied, or used as a reference > (some of the mux options are incorrect), or even just being clutter. > >

Re: New linux-next KCFLAGS

2018-11-25 Thread Stephen Rothwell
Hi Kees, On Fri, 26 Oct 2018 01:34:33 +0100 Kees Cook wrote: > > So, if you it's possible to "seed" some new flags for linux-next, I'd > be interested in making sure no new instances of warnings from > -Wimplicit-fallthrough (gcc 7.1 and later) appear. VLAs will be gone > in a couple days, so

[PATCH 5/5] arch: simplify several early memory allocations

2018-11-25 Thread Mike Rapoport
There are several early memory allocations in arch/ code that use memblock_phys_alloc() to allocate memory, convert the returned physical address to the virtual address and then set the allocated memory to zero. Exactly the same behaviour can be achieved simply by calling memblock_alloc(): it

[PATCH 4/5] openrisc: simplify pte_alloc_one_kernel()

2018-11-25 Thread Mike Rapoport
The pte_alloc_one_kernel() function allocates a page using __get_free_page(GFP_KERNEL) when mm initialization is complete and memblock_phys_alloc() on the earlier stages. The physical address of the page allocated with memblock_phys_alloc() is converted to the virtual address and in the both cases

[PATCH 3/5] sh: prefer memblock APIs returning virtual address

2018-11-25 Thread Mike Rapoport
Rather than use the memblock_alloc_base that returns a physical address and then convert this address to the virtual one, use appropriate memblock function that returns a virtual address. There is a small functional change in the allocation of then NODE_DATA(). Instead of panicing if the local

[PATCH 2/5] microblaze: prefer memblock API returning virtual address

2018-11-25 Thread Mike Rapoport
Rather than use the memblock_alloc_base that returns a physical address and then convert this address to the virtual one, use appropriate memblock function that returns a virtual address. Signed-off-by: Mike Rapoport --- arch/microblaze/mm/init.c | 5 +++-- 1 file changed, 3 insertions(+), 2

[PATCH 1/5] powerpc: prefer memblock APIs returning virtual address

2018-11-25 Thread Mike Rapoport
There are a several places that allocate memory using memblock APIs that return a physical address, convert the returned address to the virtual address and frequently also memset(0) the allocated range. Update these places to use memblock allocators already returning a virtual address; use

[PATCH 0/5] memblock: simplify several early memory allocations

2018-11-25 Thread Mike Rapoport
Hi, These patches simplify some of the early memory allocations by replacing usage of older memblock APIs with newer and shinier ones. Quite a few places in the arch/ code allocated memory using a memblock API that returns a physical address of the allocated area, then converted this physical

[PATCH] powerpc/kernel: Remove gcc 4 workaround from include/asm/io.h

2018-11-25 Thread Darren Stevens
There are verions of DEF_MMIO_IN_X and DEF_MMIO_OUT_X in asm/io.h that contain a workaround for a limitation in gcc <=4.0, but the minimum supported version of gcc is now 4.6, so these can be safely removed. Signed-off-by: Darren Stevens --- diff --git a/arch/powerpc/include/asm/io.h