Re: [PATCH 0/2] Enable ZONE_DEVICE on POWER

On 05/05/2016 08:18 PM, Aneesh Kumar K.V wrote: > Anshuman Khandual writes: > >> This enables base ZONE_DEVICE support on POWER. This series depends on >> the following patches posted by Oliver. >> >> https://patchwork.ozlabs.org/patch/618867/ >>

Re: [PATCH 2/2] powerpc: Update of_remove_property() call sites to remove null checking

On 05/05/16 16:50, Michael Ellerman wrote: > On Tue, 2016-05-03 at 15:32 -0700, Tyrel Datwyler wrote: >> On 04/27/2016 10:34 PM, Suraj Jitindar Singh wrote: >>> diff --git a/arch/powerpc/platforms/pseries/mobility.c >>> b/arch/powerpc/platforms/pseries/mobility.c >>> index ceb18d3..a560a98

[PATCH v5 3/3] powerpc: Load Monitor Register Tests

From: Jack Miller Adds two tests. One is a simple test to ensure that the new registers LMRR and LMSER are properly maintained. The other actually uses the existing EBB test infrastructure to test that LMRR and LMSER behave as documented. Signed-off-by: Jack Miller

[PATCH v5 2/3] powerpc: Load Monitor Register Support

From: Jack Miller This enables new registers, LMRR and LMSER, that can trigger an EBB in userspace code when a monitored load (via the new ldmx instruction) loads memory from a monitored space. This facility is controlled by a new FSCR bit, LM. This patch disables the FSCR LM

[PATCH v5 1/3] powerpc: Improve FSCR init and context switching

This fixes a few issues with FSCR init and switching. In this patch: powerpc: Create context switch helpers save_sprs() and restore_sprs() Author: Anton Blanchard commit 152d523e6307c7152f9986a542f873b5c5863937 We moved the setting of the FSCR register from inside an

[PATCH v5 0/3] POWER9 Load Monitor Support

This patches series adds support for the POWER9 Load Monitor instruction (ldmx) based on work from Jack Miller. The first patch is a clean up of the FSCR handling. The second patch adds the actual ldmx support to the kernel. The third patch is a couple of ldmx selftests. v5: - PATCH 1/3:

Re: [PATCH] cxl: Add kernel API to allow a context to operate with relocate disabled

On Wed, 2016-05-04 at 18:07 +0200, Frederic Barrat wrote: > Hi Ian, > > The principle is fine, but the cxl_start_context2 API bothers me a bit. > Would something similar to this make sense, I think it would keep the > API cleaner: > > /* new kernel-only API */ > void

Re: [PATCH 2/2] powerpc: Update of_remove_property() call sites to remove null checking

On 05/05/16 16:50, Michael Ellerman wrote: > On Tue, 2016-05-03 at 15:32 -0700, Tyrel Datwyler wrote: >> On 04/27/2016 > 10:34 PM, Suraj Jitindar Singh wrote: >>> diff --git > a/arch/powerpc/platforms/pseries/mobility.c > b/arch/powerpc/platforms/pseries/mobility.c >>> index ceb18d3..a560a98

Re: [PATCH kernel v4 10/11] powerpc/powernv/npu: Rework TCE Kill handling

On Thu, 5 May 2016 14:23:20 Alexey Kardashevskiy wrote: > On 05/03/2016 05:37 PM, Alistair Popple wrote: > > On Fri, 29 Apr 2016 18:55:23 Alexey Kardashevskiy wrote: > >> The pnv_ioda_pe struct keeps an array of peers. At the moment it is only > >> used to link GPU and NPU for 2 purposes: > >> >

Re: [PATCH 1/1] cxlflash: Fix to resolve dead-lock during EEH recovery

> "Uma" == Uma Krishnan writes: Uma> When a cxlflash adapter goes into EEH recovery and multiple Uma> processes (each having established its own context) are active, the Uma> EEH recovery can hang if the processes attempt to recover in Uma> parallel. The symptom

Re: [PATCH kernel v4 11/11] powerpc/powernv/npu: Enable NVLink pass through

On Thu, 5 May 2016 15:49:18 Alexey Kardashevskiy wrote: > On 05/04/2016 12:08 AM, Alistair Popple wrote: > > Hi Alexey, > > > > On Fri, 29 Apr 2016 18:55:24 Alexey Kardashevskiy wrote: > >> IBM POWER8 NVlink systems come with Tesla K40-ish GPUs each of which > >> also has a couple of fast speed

Re: [PATCH v9 21/22] drivers/of: Export of_detach_node()

On Thu, May 05, 2016 at 02:42:35PM -0500, Rob Herring wrote: >On Wed, May 04, 2016 at 11:36:03PM +1000, Gavin Shan wrote: >> On Tue, May 03, 2016 at 11:22:52PM +1000, Gavin Shan wrote: >> >This exports of_detach_node() for PowerPC PowerNV PCI hotplug >> >driver. No functional changes introduced.

[GIT PULL 00/17] perf/core improvements and fixes

/acme/linux.git tags/perf-core-for-mingo-20160505 for you to fetch changes up to b6b85dad30ad7e7394990e2317a780577974a4e6: perf evlist: Rename variable in perf_mmap__read() (2016-05-05 21:04:04 -0300) perf/core improvements

[PATCH 06/17] perf tools powerpc: Add support for generating bpf prologue

From: "Naveen N. Rao" Generalize existing macros to serve the purpose. Signed-off-by: Naveen N. Rao Cc: Ian Munsie Cc: Masami Hiramatsu Cc: Michael Ellerman Cc:

[PATCH 14/17] perf powerpc: Fix kprobe and kretprobe handling with kallsyms on ppc64le

From: "Naveen N. Rao" So far, we used to treat probe point offsets as being offset from the LEP. However, userspace applications (objdump/readelf) always show disassembly and offsets from the function GEP. This is confusing to the user as we will end up probing

[PATCH 15/17] perf symbols: Fix kallsyms perf test on ppc64le

From: "Naveen N. Rao" ppc64le functions have a Global Entry Point (GEP) and a Local Entry Point (LEP). While placing a probe, we always prefer the LEP since it catches function calls through both the GEP and the LEP. In order to do this, we fixup the function

Re: [PATCH v9 22/22] PCI/hotplug: PowerPC PowerNV PCI hotplug driver

On Thu, May 05, 2016 at 12:04:49PM -0500, Rob Herring wrote: >On Tue, May 3, 2016 at 8:22 AM, Gavin Shan wrote: >> This adds standalone driver to support PCI hotplug for PowerPC PowerNV >> platform that runs on top of skiboot firmware. The firmware identifies >>

Re: [PATCH] powerpc: Fix sstep compile on powerpcspe

On Thu, May 05, 2016 at 04:44:44PM -0400, Lennart Sorensen wrote: > powerpc: Fix sstep compile on powerpcspe > > Commit be96f63375a14ee8e690856ac77e579c75bd0bae introduced ldarx and stdcx > into the instructions in sstep.c, which are not accepted by the assembler > on powerpcspe, but does seem to

[PATCH] powerpc: Fix sstep compile on powerpcspe

powerpc: Fix sstep compile on powerpcspe Commit be96f63375a14ee8e690856ac77e579c75bd0bae introduced ldarx and stdcx into the instructions in sstep.c, which are not accepted by the assembler on powerpcspe, but does seem to be accepted by the normal powerpc assembler even in 32 bit mode. Wrap

Re: [PATCH v9 21/22] drivers/of: Export of_detach_node()

On Wed, May 04, 2016 at 11:36:03PM +1000, Gavin Shan wrote: > On Tue, May 03, 2016 at 11:22:52PM +1000, Gavin Shan wrote: > >This exports of_detach_node() for PowerPC PowerNV PCI hotplug > >driver. No functional changes introduced. > > > >Signed-off-by: Gavin Shan > >

Re: [PATCH v9 22/22] PCI/hotplug: PowerPC PowerNV PCI hotplug driver

On Tue, May 3, 2016 at 8:22 AM, Gavin Shan wrote: > This adds standalone driver to support PCI hotplug for PowerPC PowerNV > platform that runs on top of skiboot firmware. The firmware identifies > hotpluggable slots and marked their device tree node with proper >

[PATCH v2 4/8] powerpc: add io{read,write}64 accessors

This will allow device drivers to consistently use io{read,write}XX also for 64-bit accesses. Signed-off-by: Horia Geantă --- arch/powerpc/kernel/iomap.c | 24 1 file changed, 24 insertions(+) diff --git a/arch/powerpc/kernel/iomap.c

[PATCH] perf tools: add support for generating bpf prologue on powerpc

Generalize existing macros to serve the purpose. Cc: Wang Nan Cc: Arnaldo Carvalho de Melo Cc: Masami Hiramatsu Cc: Ian Munsie Cc: Michael Ellerman Signed-off-by: Naveen N. Rao

Re: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

On Thu, 5 May 2016 12:15:46 + "Tian, Kevin" wrote: > > From: Yongji Xie [mailto:xyj...@linux.vnet.ibm.com] > > Sent: Thursday, May 05, 2016 7:43 PM > > > > Hi David and Kevin, > > > > On 2016/5/5 17:54, David Laight wrote: > > > > > From: Tian, Kevin > > >> Sent:

Re: [PATCH 0/2] Enable ZONE_DEVICE on POWER

Anshuman Khandual writes: > This enables base ZONE_DEVICE support on POWER. This series depends on > the following patches posted by Oliver. > > https://patchwork.ozlabs.org/patch/618867/ > https://patchwork.ozlabs.org/patch/618868/ > > Anshuman Khandual (2): >

Re: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

On 2016/5/5 20:15, Tian, Kevin wrote: From: Yongji Xie [mailto:xyj...@linux.vnet.ibm.com] Sent: Thursday, May 05, 2016 7:43 PM Hi David and Kevin, On 2016/5/5 17:54, David Laight wrote: From: Tian, Kevin Sent: 05 May 2016 10:37 ... Acutually, we are not aimed at accessing MSI-X table

Re: [RFC PATCH v2 17/18] livepatch: change to a per-task consistency model

On Wed 2016-05-04 10:51:21, Josh Poimboeuf wrote: > On Wed, May 04, 2016 at 10:42:23AM +0200, Petr Mladek wrote: > > On Thu 2016-04-28 15:44:48, Josh Poimboeuf wrote: > > > Change livepatch to use a basic per-task consistency model. This is the > > > foundation which will eventually enable us to

[PATCH 0/2] Enable ZONE_DEVICE on POWER

This enables base ZONE_DEVICE support on POWER. This series depends on the following patches posted by Oliver. https://patchwork.ozlabs.org/patch/618867/ https://patchwork.ozlabs.org/patch/618868/ Anshuman Khandual (2): powerpc/mm: Make vmemmap_populate accommodate ZONE_DEVICE memory

RE: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

> From: Yongji Xie [mailto:xyj...@linux.vnet.ibm.com] > Sent: Thursday, May 05, 2016 7:43 PM > > Hi David and Kevin, > > On 2016/5/5 17:54, David Laight wrote: > > > From: Tian, Kevin > >> Sent: 05 May 2016 10:37 > > ... > >>> Acutually, we are not aimed at accessing MSI-X table from > >>>

[PATCH 2/2] powerpc/mm: Enable support for ZONE_DEVICE on PPC_BOOK3S_64 platforms

This enables support for the new ZONE_DEVCICE on PPC_BOOK3S_64 platforms which now accommodates device memory during memory hotplug operation. Signed-off-by: Oliver O'Halloran Signed-off-by: Anshuman Khandual --- NOTE: We need to enable

[PATCH 1/2] powerpc/mm: Make vmemmap_populate accommodate ZONE_DEVICE memory

Change the vmemmap_populate function to detect device memory through to_vmemmap_altmap and then call generic the __vmmemap_alloc_block_buf function instead of vmemmap_alloc_block as the earlier can allocate physical memory from the device range instead of the system RAM. Signed-off-by: Anshuman

Re: [PATCH 0/9] FP/VEC/VSX switching optimisations

On 2016/02/29 05:53PM, Cyril Bur wrote: > Cover-letter for V1 of the series is at > https://lists.ozlabs.org/pipermail/linuxppc-dev/2015-November/136350.html > > Cover-letter for V2 of the series is at > https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-January/138054.html > > Changes in V3:

Re: klp_task_patch: was: [RFC PATCH v2 17/18] livepatch: change to a per-task consistency model

On Wed 2016-05-04 12:57:00, Josh Poimboeuf wrote: > On Wed, May 04, 2016 at 04:48:54PM +0200, Petr Mladek wrote: > > On Thu 2016-04-28 15:44:48, Josh Poimboeuf wrote: > > > Change livepatch to use a basic per-task consistency model. This is the > > > foundation which will eventually enable us to

Re: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

On 2016/5/5 17:36, Tian, Kevin wrote: From: Yongji Xie Sent: Tuesday, May 03, 2016 3:34 PM On 2016/5/3 14:22, Tian, Kevin wrote: From: Yongji Xie [mailto:xyj...@linux.vnet.ibm.com] Sent: Tuesday, May 03, 2016 2:08 PM On 2016/5/3 13:34, Tian, Kevin wrote: From: Yongji Xie Sent: Wednesday,

Re: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

Hi David and Kevin, On 2016/5/5 17:54, David Laight wrote: From: Tian, Kevin Sent: 05 May 2016 10:37 ... Acutually, we are not aimed at accessing MSI-X table from guest. So I think it's safe to passthrough MSI-X table if we can make sure guest kernel would not touch MSI-X table in normal

Re: barriers: was: [RFC PATCH v2 17/18] livepatch: change to a per-task consistency model

On Wed 2016-05-04 12:25:17, Josh Poimboeuf wrote: > On Wed, May 04, 2016 at 04:12:05PM +0200, Petr Mladek wrote: > > On Wed 2016-05-04 14:39:40, Petr Mladek wrote: > > >* > > >* Note that the task must never be migrated to the target > > >* state when being

Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0

On Thursday 05 May 2016 09:41:32 Yangbo Lu wrote: > > -Original Message- > > From: Arnd Bergmann [mailto:a...@arndb.de] > > Sent: Thursday, May 05, 2016 4:32 PM > > To: linuxppc-dev@lists.ozlabs.org > > Cc: Yangbo Lu; linux-...@vger.kernel.org; devicet...@vger.kernel.org; > >

Re: barriers: was: [RFC PATCH v2 17/18] livepatch: change to a per-task consistency model

On Wed 2016-05-04 12:02:36, Josh Poimboeuf wrote: > On Wed, May 04, 2016 at 02:39:40PM +0200, Petr Mladek wrote: > > On Thu 2016-04-28 15:44:48, Josh Poimboeuf wrote: > > > Change livepatch to use a basic per-task consistency model. This is the > > > foundation which will eventually enable us to

RE: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

From: Tian, Kevin > Sent: 05 May 2016 10:37 ... > > Acutually, we are not aimed at accessing MSI-X table from > > guest. So I think it's safe to passthrough MSI-X table if we > > can make sure guest kernel would not touch MSI-X table in > > normal code path such as para-virtualized guest kernel on

Re: [RFC PATCH v2 17/18] livepatch: change to a per-task consistency model

On Wed, 4 May 2016, Josh Poimboeuf wrote: > On Wed, May 04, 2016 at 10:42:23AM +0200, Petr Mladek wrote: > > On Thu 2016-04-28 15:44:48, Josh Poimboeuf wrote: > > > Change livepatch to use a basic per-task consistency model. This is the > > > foundation which will eventually enable us to patch

RE: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0

Hi Arnd, > -Original Message- > From: Arnd Bergmann [mailto:a...@arndb.de] > Sent: Thursday, May 05, 2016 4:32 PM > To: linuxppc-dev@lists.ozlabs.org > Cc: Yangbo Lu; linux-...@vger.kernel.org; devicet...@vger.kernel.org; > linux-arm-ker...@lists.infradead.org;

RE: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

> From: Yongji Xie > Sent: Tuesday, May 03, 2016 3:34 PM > > On 2016/5/3 14:22, Tian, Kevin wrote: > > >> From: Yongji Xie [mailto:xyj...@linux.vnet.ibm.com] > >> Sent: Tuesday, May 03, 2016 2:08 PM > >> > >> On 2016/5/3 13:34, Tian, Kevin wrote: > >> > From: Yongji Xie > Sent:

Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0

On Thursday 05 May 2016 11:12:30 Yangbo Lu wrote: > > + fsl_guts_init(); > + svr = fsl_guts_get_svr(); > + if (svr) { > + esdhc->soc_ver = SVR_SOC_VER(svr); > + esdhc->soc_rev = SVR_REV(svr); > + } else { > + dev_err(>dev, "Failed

[RFC PATCH] mm/init: fix zone boundary creation

As a part of memory initialisation the architecture passes an array to free_area_init_nodes() which specifies the max PFN of each memory zone. This array is not necessarily monotonic (due to unused zones) so this array is parsed to build monotonic lists of the min and max PFN for each zone.

[PATCH v2 2/2] powerpc/mm: Ensure "special" zones are empty

The mm zone mechanism was traditionally used by arch specific code to partition memory into allocation zones. However there are several zones that are managed by the mm subsystem rather than the architecture. Most architectures set the max PFN of these special zones to zero, however on powerpc we

[PATCH v2 1/2] powerpc/mm: define TOP_ZONE as a constant

The zone that contains the top of memory will be either ZONE_NORMAL or ZONE_HIGHMEM depending on the kernel config. There are two functions that require this information and both of them use an #ifdef to set a local variable (top_zone). This is a little silly so lets just make it a constant.

Re: [PATCH 2/2] powerpc/mm: Ensure "special" zones are empty

On Thu, May 5, 2016 at 4:24 PM, Oliver O'Halloran wrote: > The mm zone mechanism was traditionally used by arch specific code to > partition memory into allocation zones. However there are several zones > that are managed by the mm subsystem rather than the architecture. Most >

Re: [PATCH 1/2] powerpc/mm: define TOP_ZONE as a constant

On Thu, May 5, 2016 at 4:24 PM, Oliver O'Halloran wrote: > The zone that contains the top of memory will be either ZONE_NORMAL > or ZONE_HIGHMEM depending on the kernel config. There are two functions > in that require this information and both of them use an #ifdef to set > a

Re: [PATCH 2/2] powerpc: Update of_remove_property() call sites to remove null checking

On Tue, 2016-05-03 at 15:32 -0700, Tyrel Datwyler wrote: > On 04/27/2016 10:34 PM, Suraj Jitindar Singh wrote: > > diff --git a/arch/powerpc/platforms/pseries/mobility.c > > b/arch/powerpc/platforms/pseries/mobility.c > > index ceb18d3..a560a98 100644 > > ---

[PATCH 2/2] powerpc/mm: Ensure "special" zones are empty

The mm zone mechanism was traditionally used by arch specific code to partition memory into allocation zones. However there are several zones that are managed by the mm subsystem rather than the architecture. Most architectures set the max PFN of these special zones to zero, however on powerpc we

[PATCH 1/2] powerpc/mm: define TOP_ZONE as a constant

The zone that contains the top of memory will be either ZONE_NORMAL or ZONE_HIGHMEM depending on the kernel config. There are two functions in that require this information and both of them use an #ifdef to set a local variable (top_zone). This is a little silly so lets just make it a constant.

Re: [PATCH] cxl: Ensure PSL interrupt is configured for contexts with no AFU IRQs

Le 05/05/2016 02:14, Ian Munsie a écrit : Excerpts from Frederic Barrat's message of 2016-05-05 00:26:09 +1000: I believe there's a potential problem there for powerVM guest. In afu_allocate_irqs(), the allocation of the bitmap for the AFU interrupts should return NULL (since count = 0).