Re: [PATCH 2/2] KVM: PPC: Book3S HV: lockless tlbie for HPT hcalls

On Fri, 6 Apr 2018 03:56:31 +1000 Nicholas Piggin wrote: > tlbies to an LPAR do not have to be serialised since POWER4, > MMU_FTR_LOCKLESS_TLBIE can be used to avoid the spin lock in > do_tlbies. > > Testing was done on a POWER9 system in HPT mode, with a -smp 32 guest > in

[PATCH 2/2] powerpc/mm/memtrace: Let the arch hotunplug code flush cache

Don't do this via custom code, instead now that we have support in the arch hotplug/hotunplug code, rely on those routines to do the right thing. Fixes: 9d5171a8f248 ("powerpc/powernv: Enable removal of memory for in memory tracing") because the older code uses ppc64_caches.l1d.size instead of

[PATCH 1/2] powerpc/mm: Flush cache on memory hot(un)plug

This patch adds support for flushing potentially dirty cache lines when memory is hot-plugged/hot-un-plugged. The support is currently limited to 64 bit systems. The bug was exposed when mappings for a device were actually hot-unplugged and plugged in back later. A similar issue was observed

[PATCH v3 4/4] powerpc/powernv: Create platform devs for nvdimm buses

Scan the devicetree for an nvdimm-bus compatible and create a platform device for them. Signed-off-by: Oliver O'Halloran --- arch/powerpc/platforms/powernv/opal.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/powerpc/platforms/powernv/opal.c

[PATCH v3 3/4] doc/devicetree: Persistent memory region bindings

Add device-tree binding documentation for the nvdimm region driver. Cc: devicet...@vger.kernel.org Signed-off-by: Oliver O'Halloran --- v2: Changed name from nvdimm-region to pmem-region. Cleaned up the example binding and fixed the overlapping regions. Added support

[PATCH v3 2/4] libnvdimm: Add device-tree based driver

This patch adds peliminary device-tree bindings for persistent memory regions. The driver registers a libnvdimm bus for each pmem-region node and each address range under the node is converted to a region within that bus. Signed-off-by: Oliver O'Halloran --- v2: Made each bus

[PATCH v3 1/4] libnvdimm: Add of_node to region and bus descriptors

We want to be able to cross reference the region and bus devices with the device tree node that they were spawned from. libNVDIMM handles creating the actual devices for these internally, so we need to pass in a pointer to the relevant node in the descriptor. Signed-off-by: Oliver O'Halloran

Re: [RESEND v2 3/4] doc/devicetree: Persistent memory region bindings

On Thu, 2018-04-05 at 19:25 -0700, Dan Williams wrote: > > > Please also include my niggly nit picky trivial annoying bike shed > > > color for the driver name to *not* use the "nd_region" suffix for a > > > driver registering "nvdimm_bus" objects. "of_pmem_range" or > > > "of_pmem_bus" or almost

Re: [RFC] virtio: Use DMA MAP API for devices without an IOMMU

On 04/06/2018 02:48 AM, Benjamin Herrenschmidt wrote: > On Thu, 2018-04-05 at 21:34 +0300, Michael S. Tsirkin wrote: >>> In this specific case, because that would make qemu expect an iommu, >>> and there isn't one. >> >> >> I think that you can set iommu_platform in qemu without an iommu. > > No

Re: [RESEND v2 3/4] doc/devicetree: Persistent memory region bindings

On Thu, Apr 5, 2018 at 7:14 PM, Oliver wrote: > > On Fri, Apr 6, 2018 at 12:43 AM, Dan Williams > wrote: > > On Thu, Apr 5, 2018 at 5:43 AM, Oliver wrote: > >> On Thu, Apr 5, 2018 at 10:11 PM, Michael Ellerman

Re: [RESEND v2 3/4] doc/devicetree: Persistent memory region bindings

On Fri, Apr 6, 2018 at 12:43 AM, Dan Williams wrote: > On Thu, Apr 5, 2018 at 5:43 AM, Oliver wrote: >> On Thu, Apr 5, 2018 at 10:11 PM, Michael Ellerman >> wrote: >>> Oliver writes: >>> ... For

Re: [RESEND 2/3] powerpc/memcpy: Add memcpy_mcsafe for pmem

On Thu, 05 Apr 2018 16:40:26 -0400 Jeff Moyer wrote: > Nicholas Piggin writes: > > > On Thu, 5 Apr 2018 15:53:07 +1000 > > Balbir Singh wrote: > >> I'm thinking about it, I wonder what "bytes remaining" mean in pmem context > >>

[PATCH 5/5] powerpc: Remove core support for Marvell mv64x60 hostbridges

There are no longer any platforms that use Marvell's mv64x60 hostbridges so remove the supporting kernel code. CC: Dale Farnsworth Signed-off-by: Mark Greer --- Documentation/devicetree/bindings/marvell.txt | 516 -

[PATCH 0/5] powerpc: Remove support for Marvell mv64x60 hostbridges

Hello. As far as I can tell, the c2k platform is abandoned so it should be removed. Once it is removed, there are no more platforms that use the mv64x60 hostbridge so remove that code too (and related drivers). If and when this series of patches is accepted, I will submit patches to the

[PATCH 1/5] powerpc/embedded6xx: Remove C2K board support

The C2K platform appears to be orphaned so remove code supporting it. CC: Remi Machet Signed-off-by: Mark Greer --- arch/powerpc/boot/Makefile | 5 +- arch/powerpc/boot/cuboot-c2k.c | 189 --

[PATCH 2/5] powerpc/boot: Remove support for Marvell MPSC serial controller

There are no longer any platforms that use Marvell's MPSC serial controller so remove its driver. Signed-off-by: Mark Greer --- arch/powerpc/boot/Makefile | 2 +- arch/powerpc/boot/mpsc.c | 169 - arch/powerpc/boot/ops.h

[PATCH 4/5] powerpc/boot: Remove core support for Marvell mv64x60 hostbridges

There are no longer any platforms that use Marvell's mv64x60 hostbridges so remove the supporting boot code. Signed-off-by: Mark Greer --- arch/powerpc/boot/Makefile | 2 +- arch/powerpc/boot/mv64x60.c | 581

[PATCH 3/5] powerpc/boot: Remove support for Marvell mv64x60 i2c controller

There are no longer any platforms that use Marvell's mv64x60's i2c controller so remove its driver. Signed-off-by: Mark Greer --- arch/powerpc/boot/Makefile | 2 +- arch/powerpc/boot/mv64x60_i2c.c | 204 2 files changed, 1

Re: [RFC] virtio: Use DMA MAP API for devices without an IOMMU

On Thu, 2018-04-05 at 21:34 +0300, Michael S. Tsirkin wrote: > > In this specific case, because that would make qemu expect an iommu, > > and there isn't one. > > > I think that you can set iommu_platform in qemu without an iommu. No I mean the platform has one but it's not desirable for it to

Re: [RESEND 2/3] powerpc/memcpy: Add memcpy_mcsafe for pmem

Nicholas Piggin writes: > On Thu, 5 Apr 2018 15:53:07 +1000 > Balbir Singh wrote: >> I'm thinking about it, I wonder what "bytes remaining" mean in pmem context >> in the context of a machine check exception. Also, do we want to be byte >> accurate or

[PATCH v4 03/19] powerpc: Mark variable `l` as unused, remove `path`

Add gcc attribute unused for `l` variable, replace `path` variable directly with prom_scratch. Fix warnings treated as errors with W=1: arch/powerpc/kernel/prom_init.c:607:6: error: variable ‘l’ set but not used [-Werror=unused-but-set-variable] arch/powerpc/kernel/prom_init.c:1388:8: error:

Re: [RFC] virtio: Use DMA MAP API for devices without an IOMMU

On Fri, Apr 06, 2018 at 01:09:43AM +1000, Benjamin Herrenschmidt wrote: > On Thu, 2018-04-05 at 17:54 +0300, Michael S. Tsirkin wrote: > > On Thu, Apr 05, 2018 at 08:09:30PM +0530, Anshuman Khandual wrote: > > > On 04/05/2018 04:26 PM, Anshuman Khandual wrote: > > > > There are certian platforms

[PATCH 2/2] KVM: PPC: Book3S HV: lockless tlbie for HPT hcalls

tlbies to an LPAR do not have to be serialised since POWER4, MMU_FTR_LOCKLESS_TLBIE can be used to avoid the spin lock in do_tlbies. Testing was done on a POWER9 system in HPT mode, with a -smp 32 guest in HPT mode. 32 instances of the powerpc fork benchmark from selftests were run with --fork,

[PATCH 1/2] KVM: PPC: Book3S HV: trace_tlbie must not be called in realmode

This crashes with a "Bad real address for load" attempting to load from the vmalloc region in realmode (faulting address is in DAR). Oops: Bad interrupt in KVM entry/exit code, sig: 6 [#1] LE SMP NR_CPUS=2048 NUMA PowerNV CPU: 53 PID: 6582 Comm: qemu-system-ppc Not tainted

[PATCH 0/2] KVM powerpc tlbie scalability improvement

Any reason we still need to take the tlbie lock on modern processors? Nicholas Piggin (2): KVM: PPC: Book3S HV: trace_tlbie must not be called in realmode KVM: PPC: Book3S HV: lockless tlbie for HPT hcalls arch/powerpc/kvm/book3s_hv_rm_mmu.c | 15 ++- 1 file changed, 10

[PATCH 5/5] smp: Lazy synchronization for EQS CPUs in kick_all_cpus_sync()

kick_all_cpus_sync() forces all CPUs to sync caches by sending broadcast IPI. If CPU is in extended quiescent state (idle task or nohz_full userspace), this work may be done at the exit of this state. Delaying synchronization helps to save power if CPU is in idle state and decrease latency for

[PATCH 4/5] rcu: arm64: add rcu_dynticks_eqs_exit_sync()

The following patch of the series enables delaying of kernel memory synchronization for CPUs running in extended quiescent state (EQS) till the exit of that state. In previous patch ISB was added in EQS exit path to ensure that any change made by kernel patching framework is visible. But after

[PATCH 3/5] arm64: early ISB at exit from extended quiescent state

This series enables delaying of kernel memory synchronization for CPUs running in extended quiescent state (EQS) till the exit of that state. ARM64 uses IPI mechanism to notify all cores in SMP system that kernel text is changed; and IPI handler calls isb() to synchronize. If we don't deliver

[PATCH 2/5] arm64: entry: introduce restore_syscall_args macro

Syscall arguments are passed in registers x0..x7. If assembler code has to call C functions before passing control to syscall handler, it should restore original state of that registers after the call. Currently, syscall arguments restoring is opencoded in el0_svc_naked and __sys_trace. This

[PATCH 1/5] arm64: entry: isb in el1_irq

Kernel text patching framework relies on IPI to ensure that other SMP cores observe the change. Target core calls isb() in IPI handler path, but not at the beginning of el1_irq entry. There's a chance that modified instruction will appear prior isb(), and so will not be observed. This patch

[PATCH v2 0/2] smp: don't kick CPUs running idle or nohz_full tasks

synchronization for it as well, and I didn't get comments from ppc community. v1: https://lkml.org/lkml/2018/3/25/109 Based on next-20180405 Yury Norov (5): arm64: entry: isb in el1_irq arm64: entry: introduce restore_syscall_args macro arm64: ISB early at exit from extended

Re: [mm] b1f0502d04: INFO:trying_to_register_non-static_key

On 04/04/2018 23:53, David Rientjes wrote: > On Wed, 4 Apr 2018, Laurent Dufour wrote: > >>> I also think the following is needed: >>> >>> diff --git a/fs/exec.c b/fs/exec.c >>> --- a/fs/exec.c >>> +++ b/fs/exec.c >>> @@ -312,6 +312,10 @@ static int __bprm_mm_init(struct linux_binprm *bprm) >>>

Re: [RFC 1/2] powerpc/swiotlb: Dont free up allocated SWIOTLB slab on POWER

On Wed, Apr 04, 2018 at 10:48:31PM +1000, Michael Ellerman wrote: > Anshuman Khandual writes: > > Even though SWIOTLB slab gets allocated and initialized on powerpc with > > swiotlb_init() called during mem_init(), it gets released away again on > > POWER platform

[PATCH v3] powerpc/64: Fix section mismatch warnings for early boot symbols

Some of the boot code located at the start of kernel text is "init" class, in that it only runs at boot time, however marking it as normal init code is problematic because that puts it into a different section located at the very end of kernel text. e.g., in case the TOC is not set up, we may not

Re: [RFC] virtio: Use DMA MAP API for devices without an IOMMU

On Thu, 2018-04-05 at 17:54 +0300, Michael S. Tsirkin wrote: > On Thu, Apr 05, 2018 at 08:09:30PM +0530, Anshuman Khandual wrote: > > On 04/05/2018 04:26 PM, Anshuman Khandual wrote: > > > There are certian platforms which would like to use SWIOTLB based DMA API > > > for bouncing purpose without

Re: [RESEND 2/3] powerpc/memcpy: Add memcpy_mcsafe for pmem

On Wed, Apr 4, 2018 at 11:45 PM, Nicholas Piggin wrote: > On Thu, 5 Apr 2018 15:53:07 +1000 > Balbir Singh wrote: > >> On Thu, 5 Apr 2018 15:04:05 +1000 >> Nicholas Piggin wrote: >> >> > On Wed, 4 Apr 2018 20:00:52 -0700 >> > Dan

Re: [RFC] virtio: Use DMA MAP API for devices without an IOMMU

On Thu, Apr 05, 2018 at 08:09:30PM +0530, Anshuman Khandual wrote: > On 04/05/2018 04:26 PM, Anshuman Khandual wrote: > > There are certian platforms which would like to use SWIOTLB based DMA API > > for bouncing purpose without actually requiring an IOMMU back end. But the > > virtio core does

[PATCH] powerpc/powernv: do not process OPAL events from hard interrupt context

Using irq_work for processing batches of OPAL events can cause latency spikes. irq_work is typically used just to schedule work from NMI context or for work that specifically needs to execute in interrupt context. If we are to remain with this approach to OPAL events, softirqs would be a better

Re: [RESEND v2 3/4] doc/devicetree: Persistent memory region bindings

On Thu, Apr 5, 2018 at 5:43 AM, Oliver wrote: > On Thu, Apr 5, 2018 at 10:11 PM, Michael Ellerman wrote: >> Oliver writes: >> ... >>> >>> For context Balbir is working with me on some of the pmem stuff. You >>> probably want an Ack from

Re: powerpc/64s/idle: POWER9 restore AMOR after deep sleep

On Thu, 2018-04-05 at 06:10:00 UTC, Nicholas Piggin wrote: > POWER8 restores AMOR when waking from deep sleep, but POWER9 does not, > because it does not go through the subcore restore. > > Have POWER9 restore it in core restore. > > Cc: Vaidyanathan Srinivasan >

Re: [1/2] powerpc/64s: Fix pkey support in dt_cpu_ftrs, add CPU_FTR_PKEY bit

On Thu, 2018-04-05 at 05:57:54 UTC, Nicholas Piggin wrote: > The pkey code added a CPU_FTR_PKEY bit, but did not add it to the > dt_cpu_ftrs feature set. Although capability is supported by all > processors in the base dt_cpu_ftrs set for 64s, it's a significant > and sufficiently well defined

Re: powerpc/64s: Fix dt_cpu_ftrs to have restore_cpu clear unwanted LPCR bits

On Thu, 2018-04-05 at 05:50:49 UTC, Nicholas Piggin wrote: > Presently the dt_cpu_ftrs restore_cpu will only add bits to the LPCR > for secondaries, but some bits must be removed (e.g., UPRT for HPT). > Not clearing these bits on secondaries causes checkstops when booting > with disable_radix. >

Re: [RFC] virtio: Use DMA MAP API for devices without an IOMMU

On 04/05/2018 04:26 PM, Anshuman Khandual wrote: > There are certian platforms which would like to use SWIOTLB based DMA API > for bouncing purpose without actually requiring an IOMMU back end. But the > virtio core does not allow such mechanism. Right now DMA MAP API is only > selected for

[PATCH] powerpc/64: irq_work avoid immediate interrupt when raised with hard irqs enabled

irq_work_raise should not schedule the hardware decrementer interrupt unless it is called from NMI context. Doing so often just results in an immediate masked decrementer interrupt: <...>-55090d...4us : update_curr_rt <-dequeue_task_rt <...>-55090d...5us :

Re: [PATCH v9 15/24] mm: Introduce __vm_normal_page()

On 04/04/2018 23:59, Jerome Glisse wrote: > On Wed, Apr 04, 2018 at 06:26:44PM +0200, Laurent Dufour wrote: >> >> >> On 03/04/2018 21:39, Jerome Glisse wrote: >>> On Tue, Mar 13, 2018 at 06:59:45PM +0100, Laurent Dufour wrote: When dealing with the speculative fault path we should use the

[PATCH] powerpc/64s: Fix section mismatch warnings from setup_rfi_flush()

The recent LPM changes to setup_rfi_flush() are causing some section mismatch warnings because we removed the __init annotation on setup_rfi_flush(): The function setup_rfi_flush() references the function __init ppc64_bolted_size(). the function __init memblock_alloc_base(). The references

Re: [RESEND v2 3/4] doc/devicetree: Persistent memory region bindings

On Thu, Apr 5, 2018 at 10:11 PM, Michael Ellerman wrote: > Oliver writes: > ... >> >> For context Balbir is working with me on some of the pmem stuff. You >> probably want an Ack from Rob rather than one of us. > > I'll ack it if you make all the niggly nit

Re: [PATCH v2 2/3] powerpc/memcpy: Add memcpy_mcsafe for pmem

On Thu, Apr 5, 2018 at 9:26 PM, Oliver wrote: > On Thu, Apr 5, 2018 at 5:14 PM, Balbir Singh wrote: >> The pmem infrastructure uses memcpy_mcsafe in the pmem >> layer so as to convert machine check excpetions into >> a return value on failure in case a

Re: [RESEND v2 3/4] doc/devicetree: Persistent memory region bindings

Oliver writes: ... > > For context Balbir is working with me on some of the pmem stuff. You > probably want an Ack from Rob rather than one of us. I'll ack it if you make all the niggly nit picky trivial annoying changes I asked for :D cheers

Re: [RESEND v2 3/4] doc/devicetree: Persistent memory region bindings

On Thu, Apr 5, 2018 at 12:21 AM, Dan Williams wrote: > On Wed, Apr 4, 2018 at 7:04 AM, Oliver wrote: >> On Wed, Apr 4, 2018 at 10:07 PM, Balbir Singh wrote: >>> On Tue, 3 Apr 2018 10:37:51 -0700 >>> Dan Williams

Re: [RFC] virtio: Use DMA MAP API for devices without an IOMMU

On 04/05/2018 04:44 PM, Balbir Singh wrote: > On Thu, Apr 5, 2018 at 8:56 PM, Anshuman Khandual > wrote: >> There are certian platforms which would like to use SWIOTLB based DMA API >> for bouncing purpose without actually requiring an IOMMU back end. But the >>

Re: [PATCH v2 2/3] powerpc/memcpy: Add memcpy_mcsafe for pmem

On Thu, Apr 5, 2018 at 5:14 PM, Balbir Singh wrote: > The pmem infrastructure uses memcpy_mcsafe in the pmem > layer so as to convert machine check excpetions into > a return value on failure in case a machine check > exception is encoutered during the memcpy. > > This

Re: [RFC] virtio: Use DMA MAP API for devices without an IOMMU

On Thu, Apr 5, 2018 at 8:56 PM, Anshuman Khandual wrote: > There are certian platforms which would like to use SWIOTLB based DMA API > for bouncing purpose without actually requiring an IOMMU back end. But the > virtio core does not allow such mechanism. Right now DMA

[RFC 2/2] powerpc/mm/memtrace: Let the arch hotunplug code flush cache

Don't do this via custom code, instead now that we have support in the arch hotplug/hotunplug code, rely on those routines to do the right thing. Signed-off-by: Balbir Singh --- arch/powerpc/platforms/powernv/memtrace.c | 17 - 1 file changed, 17

[RFC 1/2] powerpc/mm: Flush cache on memory hot(un)plug

This patch adds support for flushing potentially dirty cache lines when memory is hot-plugged/hot-un-plugged. The support is currently limited to 64 bit systems. The bug was exposed when mappings for a coherent memory device were actually hot-unplugged and plugged in back later. A similar issue

[RFC] virtio: Use DMA MAP API for devices without an IOMMU

There are certian platforms which would like to use SWIOTLB based DMA API for bouncing purpose without actually requiring an IOMMU back end. But the virtio core does not allow such mechanism. Right now DMA MAP API is only selected for devices which have an IOMMU and then the QEMU/host back end

[PATCH 6/6] powerpc/xive: standardise OPAL_BUSY delays

Convert to using the standard delay poll/delay form. The XIVE driver: - Did not previously loop on the OPAL_BUSY_EVENT case. - Used a 1ms sleep. Signed-off-by: Nicholas Piggin --- arch/powerpc/sysdev/xive/native.c | 193 ++ 1 file

[PATCH 5/6] powerpc/powernv: OPAL dump support standardise OPAL_BUSY delays

Convert to using the standard delay poll/delay form. The dump code: - Did not previously delay or sleep in the OPAL_BUSY case. - Used a 20ms sleep. Signed-off-by: Nicholas Piggin --- arch/powerpc/platforms/powernv/opal-dump.c | 4 +++- 1 file changed, 3 insertions(+), 1

[PATCH 4/6] powerpc/powernv: OPAL NVRAM driver standardise OPAL_BUSY delays

Convert to using the standard delay poll/delay form. The NVRAM driver: - Did not previously delay or sleep in its OPAL_BUSY loop. Signed-off-by: Nicholas Piggin --- arch/powerpc/platforms/powernv/opal-nvram.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff

[PATCH 3/6] powerpc/powernv: OPAL platform standardise OPAL_BUSY loops

Convert to using the standard delay poll/delay form. The platform code: - Used delay when called from a schedule()able context. - Did not previously delay or sleep in the OPAL_BUSY_EVENT case. Signed-off-by: Nicholas Piggin --- arch/powerpc/platforms/powernv/opal.c | 8

[PATCH 2/6] powerpc/powernv: OPAL RTC driver standardise OPAL_BUSY loops

Convert to using the standard delay poll/delay form. The OPAL RTC driver: - Did not previously delay or sleep in the OPAL_BUSY_EVENT case. There have been scheduling delays of up to 50 seconds observed here (BMC reboot can do it), which this should fix. Cc: linux-...@vger.kernel.org

[PATCH 1/6] powerpc/powernv: define a standard delay for OPAL_BUSY type retry loops

This is the start of an effort to tidy up and standardise all the delays. Existing loops have a range of delay/sleep periods from 1ms to 20ms, and some have no delay. They all loop forever except rtc, which times out after 10 retries, and that uses 10ms delays. So use 10ms as our standard delay.

[PATCH 0/6] first step of standardising OPAL_BUSY handling

Patch 1 explains most of the reasoning. Patch 1+2 and possibly 4 (just that we've seen a bug caused by the RTC driver but not yet one caused by NVRAM) could be backported as bugfixes, in most other cases the changes are inconsequential or unlikely to be a problem. Thanks, Nick Nicholas Piggin

[PATCH v2 3/3] powerpc/mce: Handle memcpy_mcsafe

Add a blocking notifier callback to be called in real-mode on machine check exceptions for UE (ld/st) errors only. The patch registers a callback on boot to be notified of machine check exceptions and returns a NOTIFY_STOP when a page of interest is seen as the source of the machine check

[PATCH v2 2/3] powerpc/memcpy: Add memcpy_mcsafe for pmem

The pmem infrastructure uses memcpy_mcsafe in the pmem layer so as to convert machine check excpetions into a return value on failure in case a machine check exception is encoutered during the memcpy. This patch largely borrows from the copyuser_power7 logic and does not add the VMX

[PATCH v2 1/3] powerpc/mce: Bug fixes for MCE handling in kernel space

The code currently assumes PAGE_SHIFT as the shift value of the pfn, this works correctly (mostly) for user space pages, but the correct thing to do is 1. Extract the shift value returned via the pte-walk API's 2. Use the shift value to access the instruction address. Note, the final physical

[PATCH v2 0/3] Add support for memcpy_mcsafe

memcpy_mcsafe() is an API currently used by the pmem subsystem to convert errors while doing a memcpy (machine check exception errors) to a return value. This patchset consists of three patches 1. The first patch is a bug fix to handle machine check errors correctly while walking the page tables

Re: [PATCH v2 03/19] powerpc: Mark variables as unused

Michael Ellerman a écrit : LEROY Christophe writes: Mathieu Malaterre a écrit : Add gcc attribute unused for two variables. Fix warnings treated as errors with W=1: arch/powerpc/kernel/prom_init.c:1388:8: error: variable

Re: [RESEND 2/3] powerpc/memcpy: Add memcpy_mcsafe for pmem

On Thu, 5 Apr 2018 15:53:07 +1000 Balbir Singh wrote: > On Thu, 5 Apr 2018 15:04:05 +1000 > Nicholas Piggin wrote: > > > On Wed, 4 Apr 2018 20:00:52 -0700 > > Dan Williams wrote: > > > > > [ adding Matthew, Christoph, and

[PATCH] powerpc/64s/idle: POWER9 restore AMOR after deep sleep

POWER8 restores AMOR when waking from deep sleep, but POWER9 does not, because it does not go through the subcore restore. Have POWER9 restore it in core restore. Cc: Vaidyanathan Srinivasan Signed-off-by: Nicholas Piggin --- Do we need this guy

[PATCH 2/2] powerpc/64s: Fix POWER9 DD2.2 and above in cputable features

The CPU_FTR_POWER9_DD2_1 flag is intended to be set for DD2.1 and above (which is what the dt_cpu_ftrs setup does). Fix cputable for DD2.2 to match. This came about due to patches b5af4f279323 ("powerpc: Add CPU feature bits for TM bug workarounds on POWER9 v2.2"), and 9e9626ed3a4a ("powerpc/64s:

[PATCH 1/2] powerpc/64s: Fix pkey support in dt_cpu_ftrs, add CPU_FTR_PKEY bit

The pkey code added a CPU_FTR_PKEY bit, but did not add it to the dt_cpu_ftrs feature set. Although capability is supported by all processors in the base dt_cpu_ftrs set for 64s, it's a significant and sufficiently well defined feature to make it optional. So add it as a quirk for now, which can

[PATCH 0/2] a couple of cpu ftrs fixes

These are a couple of differences between cputable and dt_cpu_ftrs I noticed with CPU_FTR bits. We have to be a bit careful now to keep them in sync when we change one or the other. Nicholas Piggin (2): powerpc/64s: Fix pkey support in dt_cpu_ftrs, add CPU_FTR_PKEY bit powerpc/64s: Fix POWER9