Re: [PATCH] net/ibmnvic: Fix deadlock problem in reset

Your patch is completely corrupted by your email client. Please fix this. Then, email a test patch privately to yourself. Please do not post your patch to this mailing list again until you can successfully apply the test patch you email to yourself in the step above. Thank you.

[PATCH 2/4] net/bpf: refactor freeing of executable allocations

All arch overrides of the __weak bpf_jit_free() amount to the same thing: the allocated memory was never mapped read-only, and so it does not have to be remapped to read-write before being freed. So in preparation of permitting arches to serve allocations for BPF JIT programs from other regions th

[PATCH 4/4] arm64/bpf: don't allocate BPF JIT programs in module memory

The arm64 module region is a 128 MB region that is kept close to the core kernel, in order to ensure that relative branches are always in range. So using the same region for programs that do not have this restriction is wasteful, and preferably avoided. Now that the core BPF JIT code permits the a

[PATCH 1/4] bpf: account for freed JIT allocations in arch code

Commit ede95a63b5e84 ("bpf: add bpf_jit_limit knob to restrict unpriv allocations") added a call to bpf_jit_uncharge_modmem() to the routine bpf_jit_binary_free() which is called from the __weak bpf_jit_free(). This function is overridden by arches, some of which do not call bpf_jit_binary_free() t

[PATCH 0/4] bpf: permit JIT allocations to be served outside the module region

On arm64, modules are allocated from a 128 MB window which is close to the core kernel, so that relative direct branches are guaranteed to be in range (except in some KASLR configurations). Also, module_alloc() is in charge of allocating KASAN shadow memory when running with KASAN enabled. This me

[PATCH 3/4] bpf: add __weak hook for allocating executable memory

By default, BPF uses module_alloc() to allocate executable memory, but this is not necessary on all arches and potentially undesirable on some of them. So break out the module_alloc() call into a __weak function to allow it to be overridden in arch code. Signed-off-by: Ard Biesheuvel --- kernel

[PATCH v02] powerpc/numa: Perform full re-add of CPU for PRRN/VPHN topology update

On pseries systems, performing changes to a partition's affinity can result in altering the nodes a CPU is assigned to the current system. For example, some systems are subject to resource balancing operations by the operator or control software. In such environments, system CPUs may be in node 1

[PATCH 7/7] powerpc/kconfig: remove PPC_STD_MMU_32 and PPC_STD_MMU

PPC_STD_MMU_32 and PPC_STD_MMU are not used anymore. Remove them. Signed-off-by: Christophe Leroy --- arch/powerpc/Kconfig | 2 +- arch/powerpc/platforms/Kconfig.cputype | 10 +- 2 files changed, 2 insertions(+), 10 deletions(-) diff --git a/arch/powerpc/Kconfig b/arc

[PATCH 6/7] powerpc: change CONFIG_PPC_STD_MMU to CONFIG_PPC_BOOK3S

Today we have: config PPC_BOOK3S def_bool y depends on PPC_BOOK3S_32 || PPC_BOOK3S_64 config PPC_STD_MMU def_bool y depends on PPC_BOOK3S PPC_STD_MMU is therefore redundant with PPC_BOOK3S. Lets remove it. Signed-off-by: Christophe Leroy --- arch/powerpc/mm/Mak

[PATCH 5/7] powerpc: change CONFIG_PPC_STD_MMU_32 to CONFIG_PPC_BOOK3S_32

Today we have: config PPC_BOOK3S_32 bool "512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx" [depends on PPC32 within a choice] config PPC_BOOK3S def_bool y depends on PPC_BOOK3S_32 || PPC_BOOK3S_64 config PPC_STD_MMU def_bool y depends on PPC_BOOK3S config P

[PATCH 4/7] powerpc/32: Remove #ifdef CONFIG_PPC_STD_MMU_32 in asm/book3s/32/pgtable.h

asm/book3s/32/pgtable.h is only included when CONFIG_PPC_BOOK3S_32 is set. Whenever CONFIG_PPC_BOOK3S_32 is set, CONFIG_PPC_STD_MMU_32 is set as well. This patch removes useless CONFIG_PPC_STD_MMU_32 #ifdefs Signed-off-by: Christophe Leroy --- arch/powerpc/include/asm/book3s/32/pgtable.h | 9 ++

[PATCH 3/7] powerpc/kconfig: remove CONFIG_6xx

CONFIG_6xx is not used anymore. Remove it. Signed-off-by: Christophe Leroy --- arch/powerpc/Kconfig | 2 +- arch/powerpc/platforms/512x/Kconfig| 2 +- arch/powerpc/platforms/52xx/Kconfig| 2 +- arch/powerpc/platforms/82xx/Kconfig| 4 ++-- arch/powerp

[PATCH 2/7] powerpc: change CONFIG_6xx to CONFIG_PPC_BOOK3S_32

Today we have: config PPC_BOOK3S_32 bool "512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx" [depends on PPC32 within a choice] config PPC_BOOK3S def_bool y depends on PPC_BOOK3S_32 || PPC_BOOK3S_64 config 6xx def_bool y depends on PPC32 && PPC_BOOK3S 6xx is

[PATCH 1/7] drivers/cpufreq: change CONFIG_6xx to CONFIG_PPC_BOOK3S_32

Today, powerpc has three CONFIG labels which means exactly the same: - CONFIG_6xx - CONFIG_PPC_BOOK3S_32 - CONFIG_PPC_STD_MMU_32 By consistency with PPC64, CONFIG_PPC_BOOK3S_32 is the preferred one. Using a label with includes _PPC_ also makes it clearer that it is linked to powerpc. In preparati

Re: [PATCH] arch/powerpc: Use dma_zalloc_coherent

On Sat, 2018-11-17 at 12:40 +0530, Souptick Joarder wrote: > Hi Joe, Hi back. > On Fri, Nov 16, 2018 at 12:55 AM Joe Perches wrote: > > On Thu, 2018-11-15 at 23:29 +0530, Sabyasachi Gupta wrote: > > > On Mon, Nov 5, 2018 at 8:58 AM Sabyasachi Gupta > > > wrote: > > > > Replaced dma_alloc_cohere