Re: [PATCH v3] ASoC: fsl: Convert to using %pOF instead of full_name

On Mon, Aug 07, 2017 at 06:29:18PM -0500, Rob Herring wrote: > Now that we have a custom printf format specifier, convert users of > full_name to use %pOF instead. This is preparation to remove storing > of the full path string for each node. > > Signed-off-by: Rob Herring > Cc:

Re: [PATCH 0/4] Removing full paths from DT full_name

Rob Herring writes: > On Tue, Jul 25, 2017 at 4:44 PM, Rob Herring wrote: >> This series is the last steps to remove storing the full path for every >> DT node. Instead, we can create full path strings dynamically as needed >> with printf %pOF specifiers

Re: [01/24] powerpc/mm: Move exception_enter/exit to a do_page_fault wrapper

Christophe LEROY writes: > Le 07/08/2017 à 12:41, Michael Ellerman a écrit : >> On Wed, 2017-07-19 at 04:49:23 UTC, Benjamin Herrenschmidt wrote: >>> This will allow simplifying the returns from do_page_fault >>> >>> Signed-off-by: Benjamin Herrenschmidt

Re: block/ps3vram: Delete an error message for a failed memory allocation in ps3vram_cache_init()

SF Markus Elfring writes: I didn't consider one would be triggered by the kzalloc failure. >>> >>> Do you reconsider any special system settings for further >>> software evolution then? >> >> Sorry, I don't quite understand your question. > > Do you try to

Re: [RFC PATCH v1] powerpc/radix/kasan: KASAN support for Radix

On Mon, Aug 7, 2017 at 10:30 PM, Andrey Ryabinin wrote: > On 07/29/2017 05:09 PM, Balbir Singh wrote: >> This is the first attempt to implement KASAN for radix >> on powerpc64. Aneesh Kumar implemented KASAN for hash 64 >> in limited mode (support only for kernel linear

[PATCH v3] sound: aoa: Convert to using %pOF instead of full_name

Now that we have a custom printf format specifier, convert users of full_name to use %pOF instead. This is preparation to remove storing of the full path string for each node. Signed-off-by: Rob Herring Cc: Johannes Berg Cc: Jaroslav Kysela

[PATCH v3] ASoC: fsl: Convert to using %pOF instead of full_name

Now that we have a custom printf format specifier, convert users of full_name to use %pOF instead. This is preparation to remove storing of the full path string for each node. Signed-off-by: Rob Herring Cc: Timur Tabi Cc: Nicolin Chen

Re: [PATCH 0/4] Removing full paths from DT full_name

On Tue, Jul 25, 2017 at 4:44 PM, Rob Herring wrote: > This series is the last steps to remove storing the full path for every > DT node. Instead, we can create full path strings dynamically as needed > with printf %pOF specifiers (commit ce4fecf1fe15). There are a number of >

Re: [PATCH 3/3] powerpc: replace vga_fixup() with generic code

Michael Ellerman writes: > Daniel Axtens writes: > >> Currently, we do a PCI fixup to mark a default card so that Xorg >> autoconfiguration works. >> >> There is a new generic method to do this sort of vga fixup, and >> it occurs by default. >> >> Drop our

Re: [PATCH] mtd: nand: Rename nand.h into rawnand.h

Hi Boris, On 08/04/2017 04:29 PM, Boris Brezillon wrote: [...] drivers/mtd/nand/jz4780_nand.c | 2 +- [...] For JZ4780, Acked-By: Harvey Hunt

RE: [PATCH] mtd: nand: Rename nand.h into rawnand.h

On Friday, August 04, 2017 8:29 AM, Boris Brezillon wrote: > We are planning to share more code between different NAND based > devices (SPI NAND, OneNAND and raw NANDs), but before doing that > we need to move the existing include/linux/mtd/nand.h file into > include/linux/mtd/rawnand.h so we can

Re: [PATCH] mtd: nand: Rename nand.h into rawnand.h

On 08/04/2017 10:29 AM, Boris Brezillon wrote: > We are planning to share more code between different NAND based > devices (SPI NAND, OneNAND and raw NANDs), but before doing that > we need to move the existing include/linux/mtd/nand.h file into > include/linux/mtd/rawnand.h so we can later

Re: [PATCH] mtd: nand: Rename nand.h into rawnand.h

On Fri, Aug 04, 2017 at 05:29:10PM +0200, Boris Brezillon wrote: > We are planning to share more code between different NAND based > devices (SPI NAND, OneNAND and raw NANDs), but before doing that > we need to move the existing include/linux/mtd/nand.h file into > include/linux/mtd/rawnand.h so

[v6 14/15] mm: optimize early system hash allocations

Clients can call alloc_large_system_hash() with flag: HASH_ZERO to specify that memory that was allocated for system hash needs to be zeroed, otherwise the memory does not need to be zeroed, and client will initialize it. If memory does not need to be zero'd, call the new

[v6 05/15] mm: don't accessed uninitialized struct pages

In deferred_init_memmap() where all deferred struct pages are initialized we have a check like this: if (page->flags) { VM_BUG_ON(page_zone(page) != zone); goto free_range; } This way we are checking if the current deferred page has already been initialized. It

[v6 08/15] mm: zero struct pages during initialization

Add struct page zeroing as a part of initialization of other fields in __init_single_page(). Signed-off-by: Pavel Tatashin Reviewed-by: Steven Sistare Reviewed-by: Daniel Jordan Reviewed-by: Bob Picco

[v6 15/15] mm: debug for raw alloctor

When CONFIG_DEBUG_VM is enabled, this patch sets all the memory that is returned by memblock_virt_alloc_try_nid_raw() to ones to ensure that no places excpect zeroed memory. Signed-off-by: Pavel Tatashin Reviewed-by: Steven Sistare

[v6 09/15] sparc64: optimized struct page zeroing

Add an optimized mm_zero_struct_page(), so struct page's are zeroed without calling memset(). We do eight to tent regular stores based on the size of struct page. Compiler optimizes out the conditions of switch() statement. Signed-off-by: Pavel Tatashin Reviewed-by:

[v6 01/15] x86/mm: reserve only exiting low pages

Struct pages are initialized by going through __init_single_page(). Since the existing physical memory in memblock is represented in memblock.memory list, struct page for every page from this list goes through __init_single_page(). The second memblock list: memblock.reserved, manages the

[v6 02/15] x86/mm: setting fields in deferred pages

Without deferred struct page feature (CONFIG_DEFERRED_STRUCT_PAGE_INIT), flags and other fields in "struct page"es are never changed prior to first initializing struct pages by going through __init_single_page(). With deferred struct page feature enabled there is a case where we set some fields

[v6 04/15] mm: discard memblock data later

There is existing use after free bug when deferred struct pages are enabled: The memblock_add() allocates memory for the memory array if more than 128 entries are needed. See comment in e820__memblock_setup(): * The bootstrap memblock region count maximum is 128 entries *

[v6 06/15] sparc64: simplify vmemmap_populate

Remove duplicating code by using common functions vmemmap_pud_populate and vmemmap_pgd_populate. Signed-off-by: Pavel Tatashin Reviewed-by: Steven Sistare Reviewed-by: Daniel Jordan Reviewed-by: Bob Picco

[v6 03/15] sparc64/mm: setting fields in deferred pages

Without deferred struct page feature (CONFIG_DEFERRED_STRUCT_PAGE_INIT), flags and other fields in "struct page"es are never changed prior to first initializing struct pages by going through __init_single_page(). With deferred struct page feature enabled there is a case where we set some fields

[v6 11/15] arm64/kasan: explicitly zero kasan shadow memory

To optimize the performance of struct page initialization, vmemmap_populate() will no longer zero memory. We must explicitly zero the memory that is allocated by vmemmap_populate() for kasan, as this memory does not go through struct page initialization path. Signed-off-by: Pavel Tatashin

[v6 13/15] mm: stop zeroing memory during allocation in vmemmap

Replace allocators in sprase-vmemmap to use the non-zeroing version. So, we will get the performance improvement by zeroing the memory in parallel when struct pages are zeroed. Signed-off-by: Pavel Tatashin Reviewed-by: Steven Sistare

[v6 10/15] x86/kasan: explicitly zero kasan shadow memory

To optimize the performance of struct page initialization, vmemmap_populate() will no longer zero memory. We must explicitly zero the memory that is allocated by vmemmap_populate() for kasan, as this memory does not go through struct page initialization path. Signed-off-by: Pavel Tatashin

[v6 07/15] mm: defining memblock_virt_alloc_try_nid_raw

A new variant of memblock_virt_alloc_* allocations: memblock_virt_alloc_try_nid_raw() - Does not zero the allocated memory - Does not panic if request cannot be satisfied Signed-off-by: Pavel Tatashin Reviewed-by: Steven Sistare

[v6 00/15] complete deferred page initialization

Changelog: v6 - v4 - Fixed ARM64 + kasan code, as reported by Ard Biesheuvel - Tested ARM64 code in qemu and found few more issues, that I fixed in this iteration - Added page roundup/rounddown to x86 and arm zeroing routines to zero the whole allocated range, instead of only provided address

[v6 12/15] mm: explicitly zero pagetable memory

Soon vmemmap_alloc_block() will no longer zero the block, so zero memory at its call sites for everything except struct pages. Struct page memory is zero'd by struct page initialization. Signed-off-by: Pavel Tatashin Reviewed-by: Steven Sistare

Re: block/ps3vram: Delete an error message for a failed memory allocation in ps3vram_cache_init()

On 08/07/2017 12:04 PM, SF Markus Elfring wrote: >> I think your original patch is OK, > > How does this feedback fit to the initial response “Not Applicable”? > https://patchwork.ozlabs.org/patch/798575/ I submitted your patch and a fix to ps3vram_probe() with the other patches in my queue.

[PATCH 2/3] block/ps3vram: Check return of ps3vram_cache_init

Cc: Markus Elfring Cc: Jim Paris Cc: Jens Axboe Signed-off-by: Geoff Levand --- drivers/block/ps3vram.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/block/ps3vram.c

[PATCH 3/3] powerpc/ps3: Refresh ps3_defconfig

Signed-off-by: Geoff Levand --- arch/powerpc/configs/ps3_defconfig | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/powerpc/configs/ps3_defconfig b/arch/powerpc/configs/ps3_defconfig index ee0ec5a682fc..378382683180 100644 --- a/arch/powerpc/configs/ps3_defconfig

[PATCH 1/3] block/ps3vram: Delete an error message for a failed memory allocation in ps3vram_cache_init()

From: Markus Elfring Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Link: http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf

[PATCH 0/3] Minor updates for PS3

Hi Michael, A few very minor updates for PS3. Please apply. -Geoff The following changes since commit aae4e7a8bc44722fe70d58920a36916b1043195e: Linux 4.13-rc4 (2017-08-06 18:44:49 -0700) are available in the git repository at:

Re: block/ps3vram: Delete an error message for a failed memory allocation in ps3vram_cache_init()

>>> I didn't consider one would be triggered by the kzalloc failure. >> >> Do you reconsider any special system settings for further >> software evolution then? > > Sorry, I don't quite understand your question. Do you try to configure the Linux error reporting to any special needs? > I think

Re: block/ps3vram: Delete an error message for a failed memory allocation in ps3vram_cache_init()

On 08/07/2017 11:34 AM, SF Markus Elfring wrote: >> I didn't consider one would be triggered by the kzalloc failure. > > Do you reconsider any special system settings for further > software evolution then? Sorry, I don't quite understand your question. I think your original patch is OK, and I

Re: block/ps3vram: Delete an error message for a failed memory allocation in ps3vram_cache_init()

>> Do you find the default allocation failure report insufficient? > > The default is OK. Thanks for this information. > I didn't consider one would be triggered by the kzalloc failure. Do you reconsider any special system settings for further software evolution then? Regards, Markus

Re: block/ps3vram: Delete an error message for a failed memory allocation in ps3vram_cache_init()

On 08/07/2017 09:27 AM, SF Markus Elfring wrote: >>> Omit an extra message for a memory allocation failure in this function. >>> >>> This issue was detected by using the Coccinelle software. >> >> NACK >> >> When a user asks me for help I would certainly like to get >> 'Could not allocate cache

Re: [PATCH] ipr: Fix scsi-mq lockdep issue

Brian, > Fixes the following lockdep warning that can occur when scsi-mq is > enabled with ipr due to ipr calling scsi_unblock_requests from irq > context. The fix is to move the call to scsi_unblock_requests to ipr's > existing workqueue. Applied to 4.13/scsi-fixes. Thank you! -- Martin K.

Re: [01/24] powerpc/mm: Move exception_enter/exit to a do_page_fault wrapper

Le 07/08/2017 à 12:41, Michael Ellerman a écrit : On Wed, 2017-07-19 at 04:49:23 UTC, Benjamin Herrenschmidt wrote: This will allow simplifying the returns from do_page_fault Signed-off-by: Benjamin Herrenschmidt Series applied to powerpc next, thanks.

Re: block/ps3vram: Delete an error message for a failed memory allocation in ps3vram_cache_init()

>> Omit an extra message for a memory allocation failure in this function. >> >> This issue was detected by using the Coccinelle software. > > NACK > > When a user asks me for help I would certainly like to get > 'Could not allocate cache tags' as apposed to nothing, Do you find the default

Re: [PATCH] block/ps3vram: Delete an error message for a failed memory allocation in ps3vram_cache_init()

On Mon, 2017-08-07 at 08:10 -0700, Geoff Levand wrote: > On 08/07/2017 03:52 AM, SF Markus Elfring wrote: > > Omit an extra message for a memory allocation failure in this function. > NACK > > When a user asks me for help I would certainly like to get > 'Could not allocate cache tags' as apposed

Re: [PATCH] block/ps3vram: Delete an error message for a failed memory allocation in ps3vram_cache_init()

On 08/07/2017 03:52 AM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Mon, 7 Aug 2017 12:37:01 +0200 > > Omit an extra message for a memory allocation failure in this function. > > This issue was detected by using the Coccinelle software. NACK When a

Re: [v3 PATCH 1/2] powernv/powerpc:Save/Restore additional SPRs for stop4 cpuidle

On Mon, Aug 07, 2017 at 06:26:44PM +1000, Michael Ellerman wrote: > Gautham R Shenoy writes: > > On Tue, Aug 01, 2017 at 08:56:18PM +1000, Michael Ellerman wrote: > >> "Gautham R. Shenoy" writes: > >> > > >> > Subject: [v3 PATCH 1/2]

Re: Linux 4.13: Reported regressions as of Sunday, 2017-08-06

Hi! > Hi! Find below my second regression report for Linux 4.13. It lists 10 > regressions I'm currently aware of (albeit in one case it's not entirely > clear yet if it's a regression in 4.13). One regression got fixed since > last weeks report. You can also find the report at >

Re: [RFC PATCH v1] powerpc/radix/kasan: KASAN support for Radix

On 07/29/2017 05:09 PM, Balbir Singh wrote: > This is the first attempt to implement KASAN for radix > on powerpc64. Aneesh Kumar implemented KASAN for hash 64 > in limited mode (support only for kernel linear mapping) > (https://lwn.net/Articles/655642/) > > This patch does the following: > 1.

Re: 4.13-rc3: Unrecoverable exception 4100

Nicholas Piggin writes: > On Mon, 07 Aug 2017 19:56:28 +1000 > Michael Ellerman wrote: >> Nicholas Piggin writes: >> > On Fri, 04 Aug 2017 21:54:57 +0200 >> > Andreas Schwab wrote: >> > >> >> No, this is really

Re: 4.13-rc3: Unrecoverable exception 4100

Andreas Schwab writes: > On Aug 07 2017, Michael Ellerman wrote: > >> Ah of course. Not sure why I haven't seen it in any of my testing :/ > > It took me a whole gcc bootstrap to trigger it. OK. I tried a few kernel builds, but I guess a GCC

[PATCH] block/ps3vram: Delete an error message for a failed memory allocation in ps3vram_cache_init()

From: Markus Elfring Date: Mon, 7 Aug 2017 12:37:01 +0200 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Link:

Re: powerpc/udbg: Reduce the footgun potential of EARLY_DEBUG_LPAR(_HVSI)

On Mon, 2017-07-24 at 14:10:15 UTC, Michael Ellerman wrote: > For debugging very early boot problems we have CONFIG_PPC_EARLY_DEBUG, > which allows configuring the kernel such that it unconditionally writes > to a particular type of console, regardless of whether that console > exists or not. This

Re: powerpc/configs: Add a powernv_be_defconfig

On Mon, 2017-07-24 at 12:50:45 UTC, Michael Ellerman wrote: > Although pretty much everyone using powernv is running little endian, > we should still test we can build for big endian. So add a > powernv_be_defconfig, which is autogenerated by flipping the endian > symbol in powernv_defconfig. > >

Re: [v3, 1/2] powernv/powerpc:Save/Restore additional SPRs for stop4 cpuidle

On Fri, 2017-07-21 at 10:41:37 UTC, "Gautham R. Shenoy" wrote: > From: "Gautham R. Shenoy" > > The stop4 idle state on POWER9 is a deep idle state which loses > hypervisor resources, but whose latency is low enough that it can be > exposed via cpuidle. > > Until now,

Re: powerpc/kernel: Avoid preemption check during iommu_range_alloc

On Thu, 2017-07-20 at 17:26:06 UTC, victora wrote: > Replaced __this_cpu_read function call by raw_cpu_read in > iommu_range_alloc function. > Preemption doesn't need to be disabled since any CPU can safely > use IOMMU pool. > > Signed-off-by: Victor Aoqui Applied to

Re: [01/24] powerpc/mm: Move exception_enter/exit to a do_page_fault wrapper

On Wed, 2017-07-19 at 04:49:23 UTC, Benjamin Herrenschmidt wrote: > This will allow simplifying the returns from do_page_fault > > Signed-off-by: Benjamin Herrenschmidt Series applied to powerpc next, thanks.

Re: [v2, 1/4] powerpc/mm/radix: Improve _tlbiel_pid to be usable for PWC flushes

On Wed, 2017-07-19 at 04:49:04 UTC, Benjamin Herrenschmidt wrote: > The PWC flush only needs a single set call, just like the > full (RIC=2) flush. > > This will allow us to get rid of the dedicated _tlbiel_pwc() > > Signed-off-by: Benjamin Herrenschmidt > Reviewed-by:

Re: powerpc/mm: fix a hardcode on memory boundary checking

On Thu, 2017-01-12 at 09:09:06 UTC, Rui Teng wrote: > The offset of hugepage block will not be 16G, if the expected > page is more than one. Calculate the totol size instead of the > hardcode value. > > Signed-off-by: Rui Teng > Tested-by: Anshuman Khandual

Re: 4.13-rc3: Unrecoverable exception 4100

On Aug 07 2017, Michael Ellerman wrote: > Ah of course. Not sure why I haven't seen it in any of my testing :/ It took me a whole gcc bootstrap to trigger it. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B

Re: [PATCH v3] powerpc/powernv: Use darn instr for random_seed on p9

Michael Ellerman writes: > Matt Brown writes: >> On Sat, Aug 5, 2017 at 3:06 AM, Tyrel Datwyler >> wrote: >>> On 08/03/2017 06:12 PM, Matt Brown wrote: @@ -135,8 +152,9 @@ static __init int rng_create(struct

Re: 4.13-rc3: Unrecoverable exception 4100

On Mon, 07 Aug 2017 19:56:28 +1000 Michael Ellerman wrote: > Nicholas Piggin writes: > > > On Fri, 04 Aug 2017 21:54:57 +0200 > > Andreas Schwab wrote: > > > >> No, this is really a 4.13-rc1 regression. > >> > >> Andreas. > >>

Re: 4.13-rc3: Unrecoverable exception 4100

Nicholas Piggin writes: > On Fri, 04 Aug 2017 21:54:57 +0200 > Andreas Schwab wrote: > >> No, this is really a 4.13-rc1 regression. >> >> Andreas. >> > > SLB miss with MSR[RI]=0 on > > lbz r0,THREAD+THREAD_LOAD_FP(r7) > > Caused by

Re: [v3 PATCH 1/2] powernv/powerpc:Save/Restore additional SPRs for stop4 cpuidle

Gautham R Shenoy writes: > On Tue, Aug 01, 2017 at 08:56:18PM +1000, Michael Ellerman wrote: >> "Gautham R. Shenoy" writes: >> > >> > Subject: [v3 PATCH 1/2] powernv/powerpc:Save/Restore additional SPRs for >> > stop4 cpuidle >> >> I know it's

[PATCH] powerpc/64e: Fix perf hardlockup detector build

This fixes a couple more bits of fallout when enabling the hardlockup detector for 64e. It restores the required hw_nmi_get_sample_period() function for the perf watchdog, and restores disabling of the watchdog there. It also removes API definitions that are only defined for 64s. Fixes:

[RFC PATCH v5 5/5] vfio-pci: Allow to expose MSI-X table to userspace when safe

Some devices have a MSIX BAR not aligned to the system page size greater than 4K (like 64k for ppc64) which at the moment prevents such MMIO pages from being mapped to the userspace for the sake of the MSIX BAR content protection. If such page happens to share the same system page with some

Re: [v4 PATCH 0/2] powerpc/powernv: Enable stop4 via cpuidle

On Mon, 7 Aug 2017 11:12:42 +0530 "Gautham R. Shenoy" wrote: > From: "Gautham R. Shenoy" > > Hi, > > This is the fourth iteration of the patchset to enable exploitation of > stop4 idle state on POWER9 via cpuidle. These look good to me,

[RFC PATCH v5 4/5] powerpc/iommu: Set IOMMU_GROUP_CAP_ISOLATE_MSIX

This sets IOMMU_GROUP_CAP_ISOLATE_MSIX to a group unconditionally as there is no IOMMU-capable hardware without such a feature. On IBM POWERPC (POWER8) [1], PCI host bridge maintains BFDN-to-PE translation (PE stands for "partitionable endpoint"), and PE index is used to look at Interrupt Vector

[RFC PATCH v5 2/5] iommu: Set IOMMU_GROUP_CAP_ISOLATE_MSIX if MSI controller enables IRQ remapping

This sets IOMMU_GROUP_CAP_ISOLATE_MSIX to a group if MSI remapping is enabled on an IRQ domain; this is expected to set the capability on ARM. Signed-off-by: Alexey Kardashevskiy --- drivers/iommu/iommu.c | 7 +++ 1 file changed, 7 insertions(+) diff --git

[RFC PATCH v5 1/5] iommu: Add capabilities to a group

This introduces capabilities to IOMMU groups. The first defined capability is IOMMU_GROUP_CAP_ISOLATE_MSIX which tells the IOMMU group users that a particular IOMMU group is capable of MSIX message filtering; this is useful when deciding whether or not to allow mapping of MSIX table to the

[RFC PATCH v5 3/5] iommu/intel/amd: Set IOMMU_GROUP_CAP_ISOLATE_MSIX if IRQ remapping is enabled

This sets IOMMU_GROUP_CAP_ISOLATE_MSIX to a group if IRQ remapping is enabled. For Intel, this checks disable_sourceid_checking in addition; AMD ignores the "nosid" kernel parameters. Here is some background on how the isolation works: On Intel VT-d [1], there is an Interrupt Remapping Table,

[RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

This is a followup for "[PATCH kernel v4 0/6] vfio-pci: Add support for mmapping MSI-X table" http://www.spinics.net/lists/kvm/msg152232.html This time it is using "caps" in IOMMU groups. The main question is if PCI bus flags or IOMMU domains are still better (and which one). Here is some

Re: [PATCH 3/3] powerpc: replace vga_fixup() with generic code

Daniel Axtens writes: > Currently, we do a PCI fixup to mark a default card so that Xorg > autoconfiguration works. > > There is a new generic method to do this sort of vga fixup, and > it occurs by default. > > Drop our old method. > > This method is different: > - it will

Re: [PATCH v10 4/4] irqchip/qeic: remove PPCisms for QEIC

Zhao Qiang writes: > QEIC was supported on PowerPC, and dependent on PPC, > Now it is supported on other platforms, so remove PPCisms. > > Signed-off-by: Zhao Qiang > --- > arch/powerpc/platforms/83xx/km83xx.c | 1 - >

Re: [PATCH v4] powerpc/powernv: Enable PCI peer-to-peer

Frederic Barrat writes: > diff --git a/arch/powerpc/include/asm/opal-api.h > b/arch/powerpc/include/asm/opal-api.h > index 7df005965634..2f52182a4c63 100644 > --- a/arch/powerpc/include/asm/opal-api.h > +++ b/arch/powerpc/include/asm/opal-api.h > @@ -193,7 +193,13 @@

Re: [PATCH v4] powerpc/powernv: Enable PCI peer-to-peer

On Fri, 2017-08-04 at 11:55 +0200, Frederic Barrat wrote: > P9 has support for PCI peer-to-peer, enabling a device to write in the > mmio space of another device directly, without interrupting the CPU. > > This patch adds support for it on powernv, by adding a new API to be > called by drivers.