[RFC] hwmon: (ibmpowernv) Add support for reset-history sensors

In P9, OCC allows for clearing the sensor min-max history. This patch exports attribute to reset history when set will clear the history of all the sensors owned by CSM and belonging to the chip. Signed-off-by: Shilpasri G Bhat --- This patch is on top of this

[PATCH] powerpc/powernv/pci: Return failure for some uses of dma_set_mask()

Commit 8e3f1b1d8255 ("powerpc/powernv/pci: Enable 64-bit devices to access >4GB DMA space") introduced the ability for PCI device drivers to request a DMA mask between 64 and 32 bits and actually get a mask greater than 32-bits. However currently if certain machine configuration dependent

[PATCH V8 3/3] powernv: Add support to clear sensor groups data

Adds support for clearing different sensor groups. OCC inband sensor groups like CSM, Profiler, Job Scheduler can be cleared using this driver. The min/max of all sensors belonging to these sensor groups will be cleared. Signed-off-by: Shilpasri G Bhat --- Changes

[PATCH V8 2/3] powernv: Add support to set power-shifting-ratio

This patch adds support to set power-shifting-ratio for CPU-GPU which is used by OCC power capping algorithm. Signed-off-by: Shilpasri G Bhat --- Changes from V7: - Replaced sscanf with kstrtoint arch/powerpc/include/asm/opal-api.h| 4 +-

[PATCH V8 1/3] powernv: powercap: Add support for powercap framework

Adds a generic powercap framework to change the system powercap inband through OPAL-OCC command/response interface. Signed-off-by: Shilpasri G Bhat --- Changes from V7: - Replaced sscanf with kstrtoint arch/powerpc/include/asm/opal-api.h| 5 +-

[PATCH V8 0/3] powernv : Add support for OPAL-OCC command/response interface

In P9, OCC (On-Chip-Controller) supports shared memory based commad-response interface. Within the shared memory there is an OPAL command buffer and OCC response buffer that can be used to send inband commands to OCC. The following commands are supported: 1) Set system powercap 2) Set CPU-GPU

Re: [ltc-interlock] [PATCH] hugetlb: Fix hot remove for PowerVM

Diego Domingos writes: > PowerVM has support for 16G huge pages, so the function > gigantic_page_supported needs to check if the running system > is a pseries and check if there are some gigantic page > registered. Then, we must return true - avoiding Segmentation >

Re: [RFC Part1 PATCH v3 03/17] x86/mm: Secure Encrypted Virtualization (SEV) support

On Mon, Jul 24, 2017 at 02:07:43PM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > Provide support for Secure Encyrpted Virtualization (SEV). This initial Your subject misses a verb and patch subjects should have an active verb denoting what the patch does. The

Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?

On Tue, Jul 25, 2017 at 09:02:33PM -0700, David Miller wrote: > From: "Paul E. McKenney" > Date: Tue, 25 Jul 2017 20:55:45 -0700 > > > On Tue, Jul 25, 2017 at 02:10:29PM -0700, David Miller wrote: > >> Just to report, turning softlockup back on fixes things for me on

Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?

From: "Paul E. McKenney" Date: Tue, 25 Jul 2017 20:55:45 -0700 > On Tue, Jul 25, 2017 at 02:10:29PM -0700, David Miller wrote: >> Just to report, turning softlockup back on fixes things for me on >> sparc64 too. > > Very good! > >> The thing about softlockup is it

Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?

On Tue, Jul 25, 2017 at 02:10:29PM -0700, David Miller wrote: > From: Jonathan Cameron > Date: Wed, 26 Jul 2017 00:52:07 +0800 > > > On Tue, 25 Jul 2017 08:12:45 -0700 > > "Paul E. McKenney" wrote: > > > >> On Tue, Jul 25, 2017 at

Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?

On Wed, Jul 26, 2017 at 12:52:07AM +0800, Jonathan Cameron wrote: > On Tue, 25 Jul 2017 08:12:45 -0700 > "Paul E. McKenney" wrote: > > > On Tue, Jul 25, 2017 at 10:42:45PM +0800, Jonathan Cameron wrote: > > > On Tue, 25 Jul 2017 06:46:26 -0700 > > > "Paul E. McKenney"

Re: [PATCH v2] include/linux/vfio.h: Guard powerpc-specific functions with CONFIG_VFIO_SPAPR_EEH

On Tue, Jul 18, 2017 at 02:22:20PM -0300, Murilo Opsfelder Araujo wrote: > When CONFIG_EEH=y and CONFIG_VFIO_SPAPR_EEH=n, build fails with the > following: > > drivers/vfio/pci/vfio_pci.o: In function `.vfio_pci_release': > vfio_pci.c:(.text+0xa98): undefined reference to >

Re: [PATCH v2] include/linux/vfio.h: Guard powerpc-specific functions with CONFIG_VFIO_SPAPR_EEH

On 26/07/17 01:44, Alex Williamson wrote: > [cc +Alexey, David] > > Any comments from the usual suspects for vfio/spapr? Thanks, [trying once again as mailists rejected the previous response due to broken outgoing mail encoding config in my thunderbird] Reviewed-by: Alexey Kardashevskiy

Re: [PATCH v3] powerpc/vdso64: Add support for CLOCK_{REALTIME/MONOTONIC}_COARSE

On Tue, 2017-07-25 at 19:17 +0530, Santosh Sivaraj wrote: > I get the point. I looked at the generated assembly a bit closer, the update > count is optimized out. Will send the alternative asm only patch. We could do it in C the way x86 does it, using some helpers for begin/end and have either an

Re: [PATCH v2] include/linux/vfio.h: Guard powerpc-specific functions with CONFIG_VFIO_SPAPR_EEH

On 26/07/17 01:44, Alex Williamson wrote: > [cc +Alexey, David] > > Any comments from the usual suspects for vfio/spapr? Thanks, [trying again as mailists rejected the previous response] Reviewed-by: Alexey Kardashevskiy Having EEH + VFIO_PCI and not having VFIO_SPAPR_EEH

Re: [PATCH v2] include/linux/vfio.h: Guard powerpc-specific functions with CONFIG_VFIO_SPAPR_EEH

On 26/07/17 01:44, Alex Williamson wrote: > [cc +Alexey, David] > > Any comments from the usual suspects for vfio/spapr? Thanks, Reviewed-by: Alexey Kardashevskiy Having EEH + VFIO_PCI and not having VFIO_SPAPR_EEH does not make practical sense and won't be seen in the wild

Re: [PATCH 0/4] Allow non-legacy cards to be vgaarb default

Hi Laszlo, Thanks for your input! >> Are there other graphical applications we care about (other than Xorg) >> that would need to be patched? I'm happy to do the Xorg patch, but I >> don't know if anything other than Xorg keys off the boot_vga file. >> >> I'm not fundamentally opposed to this

Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?

On Tue, 25 Jul 2017 08:12:45 -0700 "Paul E. McKenney" wrote: > On Tue, Jul 25, 2017 at 10:42:45PM +0800, Jonathan Cameron wrote: > > On Tue, 25 Jul 2017 06:46:26 -0700 > > "Paul E. McKenney" wrote: > > > > > On Tue, Jul 25, 2017 at

Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?

On Tue, 25 Jul 2017 06:46:26 -0700 "Paul E. McKenney" wrote: > On Tue, Jul 25, 2017 at 10:26:54PM +1000, Nicholas Piggin wrote: > > On Tue, 25 Jul 2017 19:32:10 +0800 > > Jonathan Cameron wrote: > > > > > Hi All, > > > > > > We

[PATCH 4/4] of/fdt: only store the device node basename in full_name

With dependencies on a statically allocated full path name converted to use %pOF format specifier, we can store just the basename of node, and the unflattening of the FDT can be simplified. This commit will affect the remaining users of full_name. After analyzing these users, the remaining cases

[PATCH 3/4] powerpc: pseries: only store the device node basename in full_name

With dependencies on full_name containing the entire device node path removed, stop storing the full_name in nodes created by dlpar_configure_connector() and pSeries_reconfig_add_node(). Signed-off-by: Rob Herring Cc: Benjamin Herrenschmidt Cc: Paul

[PATCH 2/4] powerpc: pseries: remove dlpar_attach_node dependency on full path

In preparation to stop storing the full node path in full_name, remove the dependency on full_name from dlpar_attach_node(). Callers of dlpar_attach_node() already have the parent device_node, so just pass the parent node into dlpar_attach_node instead of the path. This avoids doing a lookup of

[PATCH 1/4] powerpc: pseries: vio: match parent nodes with of_find_node_by_path

In preparation to remove the full path from device_node.full_name, use of_find_node_by_path instead of open coding with strcmp. Signed-off-by: Rob Herring Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman

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

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 remaining direct users of full_name after this series. I don't believe there

Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?

From: Jonathan Cameron Date: Wed, 26 Jul 2017 00:52:07 +0800 > On Tue, 25 Jul 2017 08:12:45 -0700 > "Paul E. McKenney" wrote: > >> On Tue, Jul 25, 2017 at 10:42:45PM +0800, Jonathan Cameron wrote: >> > On Tue, 25 Jul 2017 06:46:26 -0700

Re: [PATCH] powerpc/pseries: Fix of_node_put() underflow during pseries remove

On 07/24/2017 09:47 PM, Michael Ellerman wrote: > Tyrel Datwyler writes: > >> On 07/24/2017 03:42 AM, Michael Ellerman wrote: >>> Laurent Vivier writes: >>> As for commit 68baf692c435 ("powerpc/pseries: Fix of_node_put() underflow

RE: [PATCH 0/4] Allow non-legacy cards to be vgaarb default

Hi Laszlo [...] > > Having practically zero background in gfx development (either kernel or > Xorg), I think the problem is that vga_default_device() / > vga_set_default_device(), which -- apparently -- "boot_vga" is based > upon, come from "drivers/gpu/vga/vgaarb.c". Namely, the concept of >

Re: [PATCH v2] include/linux/vfio.h: Guard powerpc-specific functions with CONFIG_VFIO_SPAPR_EEH

[cc +Alexey, David] Any comments from the usual suspects for vfio/spapr? Thanks, Alex On Tue, 25 Jul 2017 10:56:38 -0300 Murilo Opsfelder Araújo wrote: > On 07/18/2017 02:22 PM, Murilo Opsfelder Araujo wrote: > > When CONFIG_EEH=y and CONFIG_VFIO_SPAPR_EEH=n, build

Re: [RFC Part1 PATCH v3 02/17] x86/CPU/AMD: Add the Secure Encrypted Virtualization CPU feature

On Tue, Jul 25, 2017 at 10:29:40AM -0500, Tom Lendacky wrote: > But early_identify_cpu() calls get_cpu_cap() which will check for cpuid > leaf 0x8008 support and set x86_phys_bits. Right, but it can't be less than 32, can it? And if it is more than 32 bits, then it probably doesn't really

Re: [PATCH v3 4/5] powerpc/lib/sstep: Add prty instruction emulation

On Tue, Jul 25, 2017 at 01:33:19PM +1000, Matt Brown wrote: > +static nokprobe_inline void do_prty(struct pt_regs *regs, unsigned long v, > + int size, int ra) > +{ > + unsigned long long res = v; > + > + res = (0x0001000100010001 & res) + (0x0001000100010001 &

Re: [RFC Part1 PATCH v3 02/17] x86/CPU/AMD: Add the Secure Encrypted Virtualization CPU feature

On 7/25/2017 10:13 AM, Borislav Petkov wrote: On Tue, Jul 25, 2017 at 09:58:54AM -0500, Tom Lendacky wrote: True, but it is more about being accurate and making sure the value is correct where ever it may be used. So early_identify_cpu() initializes phys_bits to 32 on 32-bit. Subtracting it

Re: [RFC Part1 PATCH v3 02/17] x86/CPU/AMD: Add the Secure Encrypted Virtualization CPU feature

On Tue, Jul 25, 2017 at 09:58:54AM -0500, Tom Lendacky wrote: > True, but it is more about being accurate and making sure the value is > correct where ever it may be used. So early_identify_cpu() initializes phys_bits to 32 on 32-bit. Subtracting it there would actually make actively it wrong,

Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?

On Tue, Jul 25, 2017 at 10:42:45PM +0800, Jonathan Cameron wrote: > On Tue, 25 Jul 2017 06:46:26 -0700 > "Paul E. McKenney" wrote: > > > On Tue, Jul 25, 2017 at 10:26:54PM +1000, Nicholas Piggin wrote: > > > On Tue, 25 Jul 2017 19:32:10 +0800 > > > Jonathan Cameron

Re: [RFC Part1 PATCH v3 01/17] Documentation/x86: Add AMD Secure Encrypted Virtualization (SEV) descrption

On 07/25/2017 12:45 AM, Borislav Petkov wrote: On Mon, Jul 24, 2017 at 02:07:41PM -0500, Brijesh Singh wrote: Subject: Re: [RFC Part1 PATCH v3 01/17] Documentation/x86: Add AMD Secure Encrypted Virtualization (SEV) descrption

Re: [RFC Part1 PATCH v3 02/17] x86/CPU/AMD: Add the Secure Encrypted Virtualization CPU feature

On 7/25/2017 9:36 AM, Borislav Petkov wrote: On Tue, Jul 25, 2017 at 09:29:40AM -0500, Tom Lendacky wrote: Yup, we can do something like that. I believe the only change that would be needed to your patch would be to move the IS_ENABLED() check to after the physical address space reduction

Re: [RFC Part1 PATCH v3 02/17] x86/CPU/AMD: Add the Secure Encrypted Virtualization CPU feature

On 7/25/2017 5:26 AM, Borislav Petkov wrote: On Mon, Jul 24, 2017 at 02:07:42PM -0500, Brijesh Singh wrote: From: Tom Lendacky Update the CPU features to include identifying and reporting on the Secure Encrypted Virtualization (SEV) feature. SME is identified by

Re: [RFC Part1 PATCH v3 02/17] x86/CPU/AMD: Add the Secure Encrypted Virtualization CPU feature

On Tue, Jul 25, 2017 at 09:29:40AM -0500, Tom Lendacky wrote: > Yup, we can do something like that. I believe the only change that > would be needed to your patch would be to move the IS_ENABLED() check > to after the physical address space reduction check. Yeah, I wasn't sure about that. The

Re: [PATCH v2] include/linux/vfio.h: Guard powerpc-specific functions with CONFIG_VFIO_SPAPR_EEH

On 07/18/2017 02:22 PM, Murilo Opsfelder Araujo wrote: > When CONFIG_EEH=y and CONFIG_VFIO_SPAPR_EEH=n, build fails with the > following: > > drivers/vfio/pci/vfio_pci.o: In function `.vfio_pci_release': > vfio_pci.c:(.text+0xa98): undefined reference to > `.vfio_spapr_pci_eeh_release' >

Re: [PATCH v3] powerpc/vdso64: Add support for CLOCK_{REALTIME/MONOTONIC}_COARSE

* Benjamin Herrenschmidt wrote (on 2017-07-25 20:07:28 +1000): > On Tue, 2017-07-25 at 12:26 +0530, Santosh Sivaraj wrote: > > > +static notrace void kernel_get_tspec(struct timespec *tp, > > +struct vdso_data *vdata, u32 *wtom_sec, > >

Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?

On Tue, Jul 25, 2017 at 10:26:54PM +1000, Nicholas Piggin wrote: > On Tue, 25 Jul 2017 19:32:10 +0800 > Jonathan Cameron wrote: > > > Hi All, > > > > We observed a regression on our d05 boards (but curiously not > > the fairly similar but single socket / smaller

Re: [PATCH v3 2/5] powerpc/lib/sstep: Add popcnt instruction emulation

On Tue, Jul 25, 2017 at 8:24 PM, David Laight wrote: > From: Linuxppc-dev > [mailto:linuxppc-dev-bounces+david.laight=aculab@lists.ozlabs.org] On > Behalf Of >> Matt Brown >> Sent: 25 July 2017 04:33 >> To: linuxppc-dev@lists.ozlabs.org >> Subject: [PATCH v3 2/5]

Re: [PATCH 0/4] Allow non-legacy cards to be vgaarb default

On 07/24/17 01:15, Daniel Axtens wrote: > Hi Ard, > >> But the fact remains that we are going about this the wrong way. >> Whether a graphics card decodes legacy VGA ranges or not has *nothing* >> to do with whether or not it is in fact the primary device on a >> non-x86 system, and so I still

Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?

On Tue, 25 Jul 2017 19:32:10 +0800 Jonathan Cameron wrote: > Hi All, > > We observed a regression on our d05 boards (but curiously not > the fairly similar but single socket / smaller core count > d03), initially seen with linux-next prior to the merge window > and

Re: [PATCH] powerpc/perf: Update default sdar_mode value for power9

On Tue, 25 Jul 2017 11:05:51 +0530 Madhavan Srinivasan wrote: > Commit 20dd4c624d251 ('powerpc/perf: Fix SDAR_MODE value for continous > sampling on Power9') set the default sdar_mode value in > MMCRA[SDAR_MODE] to be used as 0b01 (Update on TLB miss). And this > value

Re: [PATCH 5/6] powerpc/mm: Optimize detection of thread local mm's

Nicholas Piggin writes: > On Mon, 24 Jul 2017 23:46:44 +1000 > Michael Ellerman wrote: > >> Nicholas Piggin writes: >> >> > On Mon, 24 Jul 2017 14:28:02 +1000 >> > Benjamin Herrenschmidt wrote: >> > >> >>

[PATCH v6] powerpc/mm/radix: Workaround prefetch issue with KVM

From: Benjamin Herrenschmidt There's a somewhat architectural issue with Radix MMU and KVM. When coming out of a guest with AIL (Alternate Interrupt Location, ie, MMU enabled), we start executing hypervisor code with the PID register still containing whatever the guest

[PATCH v2 2/2] 44x/fsp2: enable eMMC arasan for fsp2 platform

Add mmc0 changes for enabling arasan emmc and change defconfig appropriately. Signed-off-by: Ivan Mikhaylov --- arch/powerpc/boot/dts/fsp2.dts | 33 +- arch/powerpc/configs/44x/fsp2_defconfig |2 + 2 files changed, 21 insertions(+), 14

Re: [PATCH 23/24] powerpc/mm: Cleanup check for stack expansion

LEROY Christophe writes: > Michael Ellerman a écrit : > >> LEROY Christophe writes: >> >>> Benjamin Herrenschmidt a écrit : >>> When hitting below a VM_GROWSDOWN vma (typically growing the

Re: [PATCH 5/6] powerpc/mm: Optimize detection of thread local mm's

On Tue, 25 Jul 2017 11:03:45 +1000 Benjamin Herrenschmidt wrote: > On Tue, 2017-07-25 at 10:44 +1000, Nicholas Piggin wrote: > > The two variants are just cleaner versions of the two variants you > > already introduced. > > > > static inline bool mm_activate_cpu(struct

Re: [PATCH 2/2] powernv/powerpc: Clear PECE1 in LPCR via stop-api only on Hotplug

Nicholas Piggin writes: ... > I wonder if we should think about a more structured kernel API for > modifying these kind of system registers so we always have the > up-to-date values stored in memory. Many of them do need to be > restored after sleep, but they don't need to be

Re: [RFC Part1 PATCH v3 02/17] x86/CPU/AMD: Add the Secure Encrypted Virtualization CPU feature

On Mon, Jul 24, 2017 at 02:07:42PM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > Update the CPU features to include identifying and reporting on the > Secure Encrypted Virtualization (SEV) feature. SME is identified by > CPUID 0x801f, but requires BIOS

RE: [PATCH v3 2/5] powerpc/lib/sstep: Add popcnt instruction emulation

From: Linuxppc-dev [mailto:linuxppc-dev-bounces+david.laight=aculab@lists.ozlabs.org] On Behalf Of > Matt Brown > Sent: 25 July 2017 04:33 > To: linuxppc-dev@lists.ozlabs.org > Subject: [PATCH v3 2/5] powerpc/lib/sstep: Add popcnt instruction emulation > > This adds emulations for the

Re: [PATCH v3] powerpc/vdso64: Add support for CLOCK_{REALTIME/MONOTONIC}_COARSE

On Tue, 2017-07-25 at 12:26 +0530, Santosh Sivaraj wrote: > +static notrace void kernel_get_tspec(struct timespec *tp, > + struct vdso_data *vdata, u32 *wtom_sec, > + u32 *wtom_nsec) > +{ > + u64 tb; > + u32 update_count;

RE: [RFC Part1 PATCH v3 13/17] x86/io: Unroll string I/O when SEV is active

From: Brijesh Singh > Sent: 24 July 2017 20:08 > From: Tom Lendacky > > Secure Encrypted Virtualization (SEV) does not support string I/O, so > unroll the string I/O operation into a loop operating on one element at > a time. > > Signed-off-by: Tom Lendacky

Re: [PATCH v3 4/5] powerpc/lib/sstep: Add prty instruction emulation

On Tue, 2017-07-25 at 13:33 +1000, Matt Brown wrote: > This adds emulation for the prtyw and prtyd instructions. > Tested for logical correctness against the prtyw and prtyd instructions > on ppc64le. > > Signed-off-by: Matt Brown > --- > v3: > - optimised

Re: [PATCH v3 2/5] powerpc/lib/sstep: Add popcnt instruction emulation

On Tue, 2017-07-25 at 13:33 +1000, Matt Brown wrote: > This adds emulations for the popcntb, popcntw, and popcntd instructions. > Tested for correctness against the popcnt{b,w,d} instructions on ppc64le. > > Signed-off-by: Matt Brown > --- > v3: > - optimised

[PATCH v3] powerpc/vdso64: Add support for CLOCK_{REALTIME/MONOTONIC}_COARSE

Current vDSO64 implementation does not have support for coarse clocks (CLOCK_MONOTONIC_COARSE, CLOCK_REALTIME_COARSE), for which it falls back to system call, increasing the response time, vDSO implementation reduces the cycle time. Below is a benchmark of the difference in execution time with and