Pull request: scottwood/linux.git next

Includes a fix for a powerpc/next mm regression on 64e, a fix for a kernel hang on 64e when using a debugger inside a relocated kernel, a qman fix, and misc qe improvements. The following changes since commit 096ff2ddba83bf022d593a3096d683e57c4befb0: powerpc/ftrace/64: Split further based on

Re: [GIT PULL] Please pull powerpc/linux.git powerpc-4.12-1 tag

Linus Torvalds writes: > On Fri, May 5, 2017 at 6:20 AM, Michael Ellerman wrote: >> >> Also due to a screw-up on my part, we need a hunk added when you merge >> the powerpc tree with the KVM tree: >> >> diff --git

Re: [PATCH v2] powerpc/8xx: Adding support of IRQ in MPC8xx GPIO

On Mon, May 01, 2017 at 09:38:13AM +0200, Christophe Leroy wrote: > This patch allows the use of IRQ to notify the change of GPIO status > on MPC8xx CPM IO ports. This then allows to associate IRQs to GPIOs > in the Device Tree. Wow, that's an old part. > Ex: > CPM1_PIO_C:

Re: [GIT PULL] Please pull powerpc/linux.git powerpc-4.12-1 tag

On Fri, May 5, 2017 at 6:20 AM, Michael Ellerman wrote: > > Also due to a screw-up on my part, we need a hunk added when you merge > the powerpc tree with the KVM tree: > > diff --git a/arch/powerpc/kvm/book3s_xive.c b/arch/powerpc/kvm/book3s_xive.c > index

Re: [PATCH] crypto: vmx: Remove dubiously licensed crypto code

On Fri, 2017-05-05 at 15:52 +0200, Michal Suchánek wrote: > > So you have an e-mail message from one of the authors of the code. > Andy Polyakov wrote most of the code but there are probably other > contributors who never gave explicit consent for using their code > outside of OpenSSL. The only

[v3 8/9] powerpc: teach platforms not to zero struct pages memory

If we are using deferred struct page initialization feature, most of "struct page"es are getting initialized after other CPUs are started, and hence we are benefiting from doing this job in parallel. However, we are still zeroing all the memory that is allocated for "struct pages" using the boot

[v3 0/9] parallelized "struct page" zeroing

Changelog: v2 - v3 - Addressed David's comments about one change per patch: * Splited changes to platforms into 4 patches * Made "do not zero vmemmap_buf" as a separate patch v1 - v2 - Per request, added s390 to deferred "struct page"

[v3 1/9] sparc64: simplify vmemmap_populate

Remove duplicating code, by using common functions vmemmap_pud_populate and vmemmap_pgd_populate functions. Signed-off-by: Pavel Tatashin Reviewed-by: Shannon Nelson --- arch/sparc/mm/init_64.c | 23 ++- 1 files

[v3 4/9] mm: do not zero vmemmap_buf

alloc_block_buf() can either use external allocator by calling vmemmap_alloc_block() or when available use pre-allocated vmemmap_buf to do allocation. In either case, alloc_block_buf() knows when to zero memory based on the "zero" argument. This is why it is not needed to zero vmemmap_buf

[v3 6/9] sparc64: teach sparc not to zero struct pages memory

If we are using deferred struct page initialization feature, most of "struct page"es are getting initialized after other CPUs are started, and hence we are benefiting from doing this job in parallel. However, we are still zeroing all the memory that is allocated for "struct pages" using the boot

[v3 3/9] mm: add "zero" argument to vmemmap allocators

Allow clients to request non-zeroed memory from vmemmap allocator. The following two public function have a new boolean argument called zero: __vmemmap_alloc_block_buf() vmemmap_alloc_block() When zero is true, memory that is allocated by memblock allocator is zeroed (the current behavior), when

[v3 7/9] x86: teach x86 not to zero struct pages memory

If we are using deferred struct page initialization feature, most of "struct page"es are getting initialized after other CPUs are started, and hence we are benefiting from doing this job in parallel. However, we are still zeroing all the memory that is allocated for "struct pages" using the boot

[v3 9/9] s390: teach platforms not to zero struct pages memory

If we are using deferred struct page initialization feature, most of "struct page"es are getting initialized after other CPUs are started, and hence we are benefiting from doing this job in parallel. However, we are still zeroing all the memory that is allocated for "struct pages" using the boot

[v3 5/9] mm: zero struct pages during initialization

When deferred struct page initialization is enabled, do not expect that the memory that was allocated for struct pages was zeroed by the allocator. Zero it when "struct pages" are initialized. Also, a defined boolean VMEMMAP_ZERO is provided to tell platforms whether they should zero memory or

[v3 2/9] mm: defining memblock_virt_alloc_try_nid_raw

A new version of memblock_virt_alloc_* allocations: - Does not zero the allocated memory - Does not panic if request cannot be satisfied Signed-off-by: Pavel Tatashin Reviewed-by: Shannon Nelson --- include/linux/bootmem.h |3 +++

Re: [PATCH] cxl: Unlock on error in probe

Le 05/05/2017 à 07:34, Dan Carpenter a écrit : We should unlock if get_cxl_adapter() fails. Fixes: 594ff7d067ca ("cxl: Support to flash a new image on the adapter from a guest") Signed-off-by: Dan Carpenter Acked-by: Frederic Barrat

Re: [PATCH 2/2] powerpc/fadump: avoid holes in boot memory area when fadump is registered

On Friday 05 May 2017 05:13 PM, Pingfan Liu wrote: - Original Message - From: "Hari Bathini" To: "Michael Ellerman" Cc: "linuxppc-dev" , "Pingfan Liu" , "Mahesh J Salgaonkar"

Re: [linux-next][bock] WARNING: CPU: 22 PID: 0 at block/blk-core.c:2655 .blk_update_request+0x4f8/0x500

On 05/05/2017 12:25 AM, Abdul Haleem wrote: > Hi, > > 4.11.0 Linus mainline booted with Warnings on PowerPC. > > We did not see this on next-20170407 but on next-20170410 and later. Have you tried current Linus -git? Both of the -next versions you list are rather old. -- Jens Axboe

Re: [PATCH] crypto: vmx: Remove dubiously licensed crypto code

Hello, On Thu, 30 Mar 2017 13:30:17 -0300 Paulo Flabiano Smorigo wrote: > On 2017-03-29 20:08, Tyrel Datwyler wrote: > > On 03/29/2017 08:13 AM, Michal Suchánek wrote: > >> On Wed, 29 Mar 2017 16:51:35 +0200 > >> Greg Kroah-Hartman

[GIT PULL] Please pull powerpc/linux.git powerpc-4.12-1 tag

Hi Linus, Please pull the first set of powerpc updates for 4.12. There's one conflict in kernel/kprobes.c, the resolution should look like: if (symbol_name) { addr = kprobe_lookup_name(symbol_name, offset); if (!addr) return

Re: [PATCH 2/2] powerpc/fadump: avoid holes in boot memory area when fadump is registered

- Original Message - > From: "Hari Bathini" > To: "Michael Ellerman" > Cc: "linuxppc-dev" , "Pingfan Liu" > , "Mahesh J Salgaonkar" > > Sent: Friday, May 5, 2017

[PATCH] drivers:soc:fsl:qbman:qman.c: Change a comment for an entry check inside drain_mr_fqrni function

Change the comment for an entry check inside function drain_mr_fqrni() with sleep for sufficient period of time instead of long time proccessor cycles. Signed-off-by: Karim Eshapa --- drivers/soc/fsl/qbman/qman.c | 25 + 1 file changed, 13

[PATCH] drivers:soc:fsl:qbman:qman.c: Change a comment for an entry check inside drain_mr_fqrni function

Change the comment for an entry check inside function drain_mr_fqrni() with sleep for sufficient period of time instead of long time proccessor cycles. Signed-off-by: Karim Eshapa --- drivers/soc/fsl/qbman/qman.c | 25 + 1 file changed, 13

Re: [PATCH] cxl: Unlock on error in probe

On 05/05/17 17:37, Dan Carpenter wrote: On Fri, May 05, 2017 at 05:14:15PM +1000, Andrew Donnellan wrote: sem is a global and it looks like it's intended to be held after device_open() returns and only released in device_close(), so this looks wrong. This doesn't affect the success path, it

Re: [PATCH] cxl: Unlock on error in probe

On Fri, May 05, 2017 at 09:23:02AM +0200, walter harms wrote: > > sem is a global and it looks like it's intended to be held after > > device_open() returns and only released in device_close(), so this looks > > wrong. > > > > the patch relates to the error path, do you expect a close() after

Re: [PATCH] cxl: Unlock on error in probe

On Fri, May 05, 2017 at 05:14:15PM +1000, Andrew Donnellan wrote: > sem is a global and it looks like it's intended to be held after > device_open() returns and only released in device_close(), so this looks > wrong. > This doesn't affect the success path, it only means that if device_open()

Re: [PATCH] cxl: Unlock on error in probe

Am 05.05.2017 09:14, schrieb Andrew Donnellan: > On 05/05/17 15:34, Dan Carpenter wrote: >> We should unlock if get_cxl_adapter() fails. >> >> Fixes: 594ff7d067ca ("cxl: Support to flash a new image on the adapter >> from a guest") >> Signed-off-by: Dan Carpenter >> >>

Re: [PATCH] cxl: Unlock on error in probe

On 05/05/17 15:34, Dan Carpenter wrote: We should unlock if get_cxl_adapter() fails. Fixes: 594ff7d067ca ("cxl: Support to flash a new image on the adapter from a guest") Signed-off-by: Dan Carpenter diff --git a/drivers/misc/cxl/flash.c b/drivers/misc/cxl/flash.c

[PATCH] powerpc/64e: Don't place the stack beyond TASK_SIZE

Commit f4ea6dcb08ea ("powerpc/mm: Enable mappings above 128TB") increased the task size on book3s, and introduced a mechanism to dynamically control whether a task uses these larger addresses. While the change to the task size itself was ifdef-protected to only apply on book3s, the change to

Re: [PATCH 2/2] powerpc/fadump: avoid holes in boot memory area when fadump is registered

On 05/04/2017 11:24 PM, Hari Bathini wrote: > To register fadump, boot memory area - the size of low memory chunk that > is required for a kernel to boot successfully when booted with restricted > memory, is assumed to have no holes. But this memory area is currently > not protected from

Re: [PATCH 1/2] powerpc/fadump: avoid duplicates in crash memory ranges

On 05/04/2017 11:23 PM, Hari Bathini wrote: > fadump sets up crash memory ranges to be used for creating PT_LOAD > program headers in elfcore header. Memory chunk RMA_START through > boot memory area size is added as the first memory range because > firmware, at the time of crash, moves this

Re: [linux-next][bisected 1945bc45] build brakes for PowerPC BE configuration on LPAR

On Fri, 05 May 2017 09:40:10 +0530 Abdul Haleem wrote: > On Thu, 2017-05-04 at 20:41 +1000, Nicholas Piggin wrote: > > On Thu, 04 May 2017 14:54:19 +0530 > > Abdul Haleem wrote: > > > > > Hi, > > > > > > linux-next build fails on BE

Re: [PATCH v2] drivers:soc:fsl:qbman:qman.c: Sleep instead of stuck hacking jiffies.

On Fri, 2017-05-05 at 08:01 +0200, Karim Eshapa wrote: > > On 5/4/2017 5:07 PM, Scott Wood wrote: > > > On Thu, 2017-05-04 at 06:58 +0200, Karim Eshapa wrote: > > > > +stop = jiffies + 1; > > > > +/* > > > > + * if MR was full and h/w had other FQRNI entries to produce, we > > > >

[linux-next][bock] WARNING: CPU: 22 PID: 0 at block/blk-core.c:2655 .blk_update_request+0x4f8/0x500

Hi, 4.11.0 Linus mainline booted with Warnings on PowerPC. We did not see this on next-20170407 but on next-20170410 and later. Machine type: Power 7 PowerVM LPAR Kernel : 4.11.0 Config : file attched. IPv6: ADDRCONF(NETDEV_UP): net0: link is not ready Starting WPA Supplicant daemon...

RE: [PATCH v2] drivers:soc:fsl:qbman:qman.c: Sleep instead of stuck hacking jiffies.

>On 5/4/2017 5:07 PM, Scott Wood wrote: >> On Thu, 2017-05-04 at 06:58 +0200, Karim Eshapa wrote: >>> +stop = jiffies + 1; >>> +/* >>> + * if MR was full and h/w had other FQRNI entries to produce, we >>> + * need to allow it time to produce those entries once the >>> + *