Re: [PATCH v3 02/10] mtd: powernv_flash: Lock around concurrent access to OPAL

On Mon, 2017-07-17 at 17:34 +1000, Balbir Singh wrote: > On Wed, 2017-07-12 at 14:22 +1000, Cyril Bur wrote: > > OPAL can only manage one flash access at a time and will return an > > OPAL_BUSY error for each concurrent access to the flash. The simplest > > way to prevent this from happening is

[PATCH] [PING] Fix TIOCGPTPEER ioctl definition

This ioctl does nothing to justify an _IOC_READ or _IOC_WRITE flag because it doesn't copy anything from/to userspace to access the argument. Fixes: 54ebbfb16034 ("tty: add TIOCGPTPEER ioctl") Signed-off-by: Gleb Fotengauer-Malinovskiy Acked-by: Aleksa Sarai

Re: [PATCH] powerpc/powernv: Fix boot on Power8 bare metal due to opal_configure_cores()

On Mon, 2017-07-17 at 21:31 +1000, Michael Ellerman wrote: > In commit 1c0eaf0f56d6 ("powerpc/powernv: Tell OPAL about our MMU mode > on POWER9"), we added additional flags to the OPAL call to configure > CPUs at boot. > > These flags only work on Power9 firmwares, and worse can cause boot >

Re: [PATCH/RFC] powerpc: Better handle "error" type page faults on book3s64

On Fri, 2017-07-14 at 18:31 +1000, Benjamin Herrenschmidt wrote: > There are a number of conditions in the DSISR that represent > conditions for which there is no point looking for a VMA or > trying to update a PTE. In fact, POWER9 adds a few with bad > AMOs, bad "paste" instruction etc... > >

Re: Kernel build issues with upstream binutils

Hi, On bissecting kernel on Debian (gcc version 6.3.0 20170516) I've got the same error on linking kernels <= v4.9 as reported previously in this thread: ld: arch/powerpc/boot/zImage.pseries: Not enough room for program headers, try linking with -N ld: final link failed: Bad value

Re: [PATCH v3 06/10] powerpc/opal: Rework the opal-async interface

On Wed, 2017-07-12 at 14:23 +1000, Cyril Bur wrote: > Future work will add an opal_async_wait_response_interruptible() > which will call wait_event_interruptible(). This work requires extra > token state to be tracked as wait_event_interruptible() can return and > the caller could release the

[PATCH v2] powerpc: allow compiling with GENERIC_MSI_IRQ_DOMAIN

From: Laurentiu Tudor This allows building powerpc with the GENERIC_MSI_IRQ_DOMAIN Kconfig by enabling the asm-generic msi.h in Kbuild. Without this, there's a compilation error [1] because powerpc, as most arches, doesn't provide an asm/msi.h. [1] In file included from

Re: [PATCH 1/3] PCI: dwc: Handle host_init failures

Hi Bjorn Andersson, Às 7:39 AM de 7/16/2017, Bjorn Andersson escreveu: > In several dwc based drivers host_init can fail, so make sure to > propagate and handle this to avoid continuing operation of a driver or > hardware in an invalid state. > > Signed-off-by: Bjorn Andersson

Re: [PATCH v3 01/10] mtd: powernv_flash: Use WARN_ON_ONCE() rather than BUG_ON()

On Wed, Jul 12, 2017 at 6:22 AM, Cyril Bur wrote: > BUG_ON() should be reserved in situations where we can not longer > guarantee the integrity of the system. In the case where > powernv_flash_async_op() receives an impossible op, we can still > guarantee the integrity of the

Re: [PATCH 3/4] powerpc/mm/radix: Avoid flushing the PWC on every flush_tlb_range

Hi Benjamin, [auto build test ERROR on powerpc/next] [also build test ERROR on v4.13-rc1 next-20170717] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Benjamin-Herrenschmidt/powerpc-mm-radix

Re: Kernel build issues with upstream binutils

No sure if in reply-to took correct effect, so I'm posting the thread ref explicit: https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-November/151672.html On 17-07-2017 09:57, Gustavo Romero wrote: > Hi, > > On bissecting kernel on Debian (gcc version 6.3.0 20170516) I've got the same >

[PATCH] powerpc/powernv: Fix boot on Power8 bare metal due to opal_configure_cores()

In commit 1c0eaf0f56d6 ("powerpc/powernv: Tell OPAL about our MMU mode on POWER9"), we added additional flags to the OPAL call to configure CPUs at boot. These flags only work on Power9 firmwares, and worse can cause boot failures on Power8 machines, so we check for CPU_FTR_ARCH_300 (aka POWER9)

Re: [PATCH v3 03/10] mtd: powernv_flash: Don't treat OPAL_SUCCESS as an error

On Wed, 2017-07-12 at 14:22 +1000, Cyril Bur wrote: > While this driver expects to interact asynchronously, OPAL is well > within its rights to return OPAL_SUCCESS to indicate that the operation > completed without the need for a callback. We shouldn't treat > OPAL_SUCCESS as an error rather we

Re: [PATCH v3 02/10] mtd: powernv_flash: Lock around concurrent access to OPAL

On Wed, 2017-07-12 at 14:22 +1000, Cyril Bur wrote: > OPAL can only manage one flash access at a time and will return an > OPAL_BUSY error for each concurrent access to the flash. The simplest > way to prevent this from happening is with a mutex. > > Signed-off-by: Cyril Bur

Re: [PATCH] ptrace: Add compat PTRACE_{G,S}ETSIGMASK handlers

James Morse writes: > compat_ptrace_request() lacks handlers for PTRACE_{G,S}ETSIGMASK, > instead using those in ptrace_request(). The compat variant should > read a compat_sigset_t from userspace instead of ptrace_request()s > sigset_t. > > While compat_sigset_t is the same

Re: [PATCH v3 02/10] mtd: powernv_flash: Lock around concurrent access to OPAL

On Mon, 2017-07-17 at 17:55 +1000, Cyril Bur wrote: > On Mon, 2017-07-17 at 17:34 +1000, Balbir Singh wrote: > > On Wed, 2017-07-12 at 14:22 +1000, Cyril Bur wrote: > > > OPAL can only manage one flash access at a time and will return an > > > OPAL_BUSY error for each concurrent access to the

Re: [PATCH] [PING] Fix TIOCGPTPEER ioctl definition

On Mon, Jul 17, 2017 at 04:29:46PM +0300, Gleb Fotengauer-Malinovskiy wrote: > This ioctl does nothing to justify an _IOC_READ or _IOC_WRITE flag > because it doesn't copy anything from/to userspace to access the > argument. > > Fixes: 54ebbfb16034 ("tty: add TIOCGPTPEER ioctl") > Signed-off-by:

Applied "ASoC: fsl_asrc: constify snd_soc_dai_ops structure" to the asoc tree

The patch ASoC: fsl_asrc: constify snd_soc_dai_ops structure has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and

Applied "ASoC: fsl_esai: constify snd_soc_dai_ops structure" to the asoc tree

The patch ASoC: fsl_esai: constify snd_soc_dai_ops structure has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and

Applied "ASoC: fsl_spdif: constify snd_soc_dai_ops structure" to the asoc tree

The patch ASoC: fsl_spdif: constify snd_soc_dai_ops structure has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and

Re: [PATCH] ptrace: Add compat PTRACE_{G,S}ETSIGMASK handlers

Hi Michael, On 17/07/17 11:17, Michael Ellerman wrote: > James Morse writes: >> compat_ptrace_request() lacks handlers for PTRACE_{G,S}ETSIGMASK, >> instead using those in ptrace_request(). The compat variant should >> read a compat_sigset_t from userspace instead of

Re: [PATCH 1/3] PCI: dwc: Handle host_init failures

On Monday, July 17, 2017 7:18 AM, Joao Pinto wrote: > > Hi Bjorn Andersson, > > Às 7:39 AM de 7/16/2017, Bjorn Andersson escreveu: > > In several dwc based drivers host_init can fail, so make sure to > > propagate and handle this to avoid continuing operation of a driver or > > hardware in an

[PATCH V2 4/6] crypto/nx: Add nx842_add_coprocs_list function

Updating coprocessor list is moved to nx842_add_coprocs_list(). This function will be used for both icswx and VAS functions. Signed-off-by: Haren Myneni --- drivers/crypto/nx/nx-842-powernv.c | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git

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

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. The pnv_pci_set_p2p(...) call configures an 'initiator', i.e the

Re: [PATCH v3 01/10] mtd: powernv_flash: Use WARN_ON_ONCE() rather than BUG_ON()

On Mon, 2017-07-17 at 13:33 +0200, Frans Klaver wrote: > On Wed, Jul 12, 2017 at 6:22 AM, Cyril Bur wrote: > > BUG_ON() should be reserved in situations where we can not longer > > guarantee the integrity of the system. In the case where > > powernv_flash_async_op() receives

Re: [PATCH 2/3] powerpc/mm/hash: Refactor hash__mark_rodata_ro()

On Fri, Jul 14, 2017 at 4:51 PM, Michael Ellerman wrote: > Move the core logic into a helper, so we can use it for changing other > permissions. > > We also change the logic to align start down, and end up. This means > calling the function with a range will expand that range

Re: [PATCH 1/3] powerpc/mm/radix: Refactor radix__mark_rodata_ro()

On Fri, Jul 14, 2017 at 4:51 PM, Michael Ellerman wrote: > Move the core logic into a helper, so we can use it for changing permissions > other than _PAGE_WRITE. > > Signed-off-by: Michael Ellerman > --- > arch/powerpc/mm/pgtable-radix.c | 20

Re: [PATCH v3 02/10] mtd: powernv_flash: Lock around concurrent access to OPAL

Cyril Bur writes: > On Mon, 2017-07-17 at 19:29 +1000, Balbir Singh wrote: >> On Mon, 2017-07-17 at 17:55 +1000, Cyril Bur wrote: >> > On Mon, 2017-07-17 at 17:34 +1000, Balbir Singh wrote: >> > > On Wed, 2017-07-12 at 14:22 +1000, Cyril Bur wrote: >> > > > OPAL can only

Re: [PATCH v3 06/10] powerpc/opal: Rework the opal-async interface

Cyril Bur writes: > On Mon, 2017-07-17 at 21:30 +1000, Balbir Singh wrote: >> On Wed, 2017-07-12 at 14:23 +1000, Cyril Bur wrote: >> > static int __opal_async_get_token(void) >> > { >> >unsigned long flags; >> >int token; >> > >> > -

Re: [PATCH 2/2] mtd: powernv_flash: Lock around concurrent access to OPAL

Cyril Bur writes: > OPAL can only manage one flash access at a time and will return an > OPAL_BUSY error for each concurrent access to the flash. The simplest > way to prevent this from happening is with a mutex. > > Signed-off-by: Cyril Bur > --- > This

[PATCH] powerpc/64s: Fix hypercall entry clobbering r12 input

A previous optimisation incorrectly assumed the PAPR hcall does not use r12, and clobbers it upon entry. In fact it is used as an input. This can result in KVM guests crashing (observed with PR KVM). Instead of using r12 to save r13, tihs patch saves r13 in ctr. This is more costly, but not as

[PATCH V2 0/6] Enable NX 842 compression engine on Power9

[PATCH V2 0/6] Enable NX 842 compression engine on Power9 P9 introduces Virtual Accelerator Switchboard (VAS) to communicate with NX 842 engine. icswx function is used to access NX before. On powerNV systems, NX-842 driver invokes VAS functions for configuring RxFIFO (receive window) per each NX

[PATCH V2 5/6] crypto/nx: Add P9 NX specific error codes for 842 engine

This patch adds changes for checking P9 specific 842 engine error codes. These errros are reported in coprocessor status block (CSB) for failures. Signed-off-by: Haren Myneni --- arch/powerpc/include/asm/icswx.h | 3 +++ drivers/crypto/nx/nx-842-powernv.c | 18

Re: [PATCH v3 03/10] mtd: powernv_flash: Don't treat OPAL_SUCCESS as an error

On Mon, 2017-07-17 at 18:50 +1000, Balbir Singh wrote: > On Wed, 2017-07-12 at 14:22 +1000, Cyril Bur wrote: > > While this driver expects to interact asynchronously, OPAL is well > > within its rights to return OPAL_SUCCESS to indicate that the operation > > completed without the need for a

Re: [PATCH v3 02/10] mtd: powernv_flash: Lock around concurrent access to OPAL

On Mon, 2017-07-17 at 19:29 +1000, Balbir Singh wrote: > On Mon, 2017-07-17 at 17:55 +1000, Cyril Bur wrote: > > On Mon, 2017-07-17 at 17:34 +1000, Balbir Singh wrote: > > > On Wed, 2017-07-12 at 14:22 +1000, Cyril Bur wrote: > > > > OPAL can only manage one flash access at a time and will return

[PATCH V2 1/6] crypto/nx842: Rename nx842_powernv_function as icswx function

Rename nx842_powernv_function to nx842_powernv_exec. nx842_powernv_exec points to nx842_exec_icswx and will be point to VAS exec function which will be added later for P9 NX support. Signed-off-by: Haren Myneni --- drivers/crypto/nx/nx-842-powernv.c | 20 +---

[PATCH V2 2/6] crypto/nx: Create nx842_configure_crb function

Configure CRB is moved to nx842_configure_crb() so that it can be used for icswx and VAS exec functions. VAS function will be added later with P9 support. Signed-off-by: Haren Myneni --- drivers/crypto/nx/nx-842-powernv.c | 57 +- 1 file

[PATCH V2 3/6] crypto/nx: Create nx842_delete_coprocs function

Move deleting coprocessors info upon exit or failure to nx842_delete_coprocs(). Signed-off-by: Haren Myneni --- drivers/crypto/nx/nx-842-powernv.c | 25 - 1 file changed, 12 insertions(+), 13 deletions(-) diff --git

[PATCH V2 6/6] crypto/nx: Add P9 NX support for 842 compression engine

This patch adds P9 NX support for 842 compression engine. Virtual Accelerator Switchboard (VAS) is used to access 842 engine on P9. For each NX engine per chip, setup receive window using vas_rx_win_open() which configures RxFIFo with FIFO address, lpid, pid and tid values. This unique (lpid,

Re: [PATCH v3 06/10] powerpc/opal: Rework the opal-async interface

On Mon, 2017-07-17 at 21:30 +1000, Balbir Singh wrote: > On Wed, 2017-07-12 at 14:23 +1000, Cyril Bur wrote: > > Future work will add an opal_async_wait_response_interruptible() > > which will call wait_event_interruptible(). This work requires extra > > token state to be tracked as

Re: [linux-next][bisected 1c0eaf0f] Today's next kernel fails to boot on ppc bare-metal

> > Machine: Power 8 bare-metal > > kernel: 4.12.0-next-20170713 > > gcc: version 4.8.5 > > config : Tul-NV-config attached. > > [swearing redacted] > > Does this help? Yes, it fixes the boot issue. Thanks for the fix. With below patch, I was able to successfull

Re: [PATCH v3 01/10] mtd: powernv_flash: Use WARN_ON_ONCE() rather than BUG_ON()

On Wed, 2017-07-12 at 14:22 +1000, Cyril Bur wrote: > BUG_ON() should be reserved in situations where we can not longer > guarantee the integrity of the system. In the case where > powernv_flash_async_op() receives an impossible op, we can still > guarantee the integrity of the system. > >