On Fri, May 11, 2018 at 9:59 AM, Abdul Haleem
wrote:
> Greeting's
>
> Today's next kernel on powerpc machine has boot warnings with commit
>
> a794d8d : crypto: ccree - enable support for hardware keys
Adding the crypto list and maintainer as it came in via the crypto tree.
>
> Warning disappear
The GETFIELD and SETFIELD macros in xive-regs.h aren't used except for a
single instance of GETFIELD, so replace that and remove them.
These macros are also defined in vas.h, so either those should be
eventually replaced or the macros moved into bitops.h.
Signed-off-by: Russell Currey
---
arch/
Due to a snafu "paes" testmgr tests were not ordered
lexicographically, which led to boot time warnings.
Reorder the tests as needed.
Fixes: a794d8d ("crypto: ccree - enable support for hardware keys")
Reported-by: Abdul Haleem
Signed-off-by: Gilad Ben-Yossef
---
crypto/testmgr.c | 44 +
Le 11/05/2018 à 08:12, Alastair D'Silva a écrit :
From: Alastair D'Silva
This patch adds a CPU feature bit to show whether the CPU has
the TIDR register available, enabling as_notify/wait in userspace.
Signed-off-by: Alastair D'Silva
---
Reviewed-by: Frederic Barrat
arch/powerpc/in
Le 11/05/2018 à 08:12, Alastair D'Silva a écrit :
From: Alastair D'Silva
Switch the use of TIDR on it's CPU feature, rather than assuming it
is available based on architecture.
Signed-off-by: Alastair D'Silva
---
Reviewed-by: Frederic Barrat
arch/powerpc/kernel/process.c | 6 +++---
Le 11/05/2018 à 08:12, Alastair D'Silva a écrit :
From: Alastair D'Silva
The current implementation of TID allocation, using a global IDR, may
result in an errant process starving the system of available TIDs.
Instead, use task_pid_nr(), as mentioned by the original author. The
scenario descr
Le 11/05/2018 à 08:13, Alastair D'Silva a écrit :
From: Alastair D'Silva
The function removes the process element from NPU cache.
Signed-off-by: Alastair D'Silva
---
Acked-by: Frederic Barrat
arch/powerpc/include/asm/pnv-ocxl.h | 2 +-
arch/powerpc/platforms/powernv/ocxl.c | 4 ++-
Le 11/05/2018 à 08:13, Alastair D'Silva a écrit :
From: Alastair D'Silva
In order to successfully issue as_notify, an AFU needs to know the TID
to notify, which in turn means that this information should be
available in userspace so it can be communicated to the AFU.
Signed-off-by: Alastair
Le 11/05/2018 à 08:13, Alastair D'Silva a écrit :
From: Alastair D'Silva
In order for a userspace AFU driver to call the POWER9 specific
OCXL_IOCTL_ENABLE_P9_WAIT, it needs to verify that it can actually
make that call.
Signed-off-by: Alastair D'Silva
---
Acked-by: Frederic Barrat
d
Le 11/05/2018 à 08:13, Alastair D'Silva a écrit :
From: Alastair D'Silva
Signed-off-by: Alastair D'Silva
---
Acked-by: Frederic Barrat
Documentation/accelerators/ocxl.rst | 11 +++
1 file changed, 11 insertions(+)
diff --git a/Documentation/accelerators/ocxl.rst
b/Document
Le 17/04/2018 à 16:53, Souptick Joarder a écrit :
Use new return type vm_fault_t for fault handler. For
now, this is just documenting that the function returns
a VM_FAULT value rather than an errno. Once all instances
are converted, vm_fault_t will become a distinct type.
Reference id -> 1c8f4
Le 11/05/2018 à 12:06, Alastair D'Silva a écrit :
-Original Message-
From: Frederic Barrat
Sent: Friday, 11 May 2018 7:25 PM
To: Alastair D'Silva ; linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org; linux-...@vger.kernel.org;
mi...@neuling.org; vaib...@linux.vnet.ibm.com
From: "Gautham R. Shenoy"
Each of the SMT4 cores forming a fused-core are more or less
independent units. Thus when multiple tasks are scheduled to run on
the fused core, we get the best performance when the tasks are spread
across the pair of SMT4 cores.
Since the threads in the pair of SMT4 co
From: "Gautham R. Shenoy"
Hi,
A pair of IBM POWER9 SMT4 cores can be fused together to form a
big-core with 8 SMT threads. This can be discovered via the
"ibm,thread-groups" CPU property in the device tree which will
indicate which group of threads that share the L1 cache, translation
cache and
From: "Gautham R. Shenoy"
A pair of IBM POWER9 SMT4 cores can be fused together to form a
big-core with 8 SMT threads. This can be discovered via the
"ibm,thread-groups" CPU property in the device tree which will
indicate which group of threads that share the L1 cache, translation
cache and instr
Le 25/04/2018 à 13:08, Philippe Bergheaud a écrit :
Skiboot used to set the default Tunnel BAR register value when capi mode
was enabled. This approach was ok for the cxl driver, but prevented other
drivers from choosing different values.
Skiboot versions > 5.11 will not set the default value
Le 25/04/2018 à 13:08, Philippe Bergheaud a écrit :
Failure to synchronize the tunneled operations does not prevent
the initialization of the cxl card. This patch reports the tunneled
operations status via /sys.
Signed-off-by: Philippe Bergheaud
---
Good idea, but you'll have to also edit
D
> -Original Message-
> From: Frederic Barrat
> Sent: Friday, 11 May 2018 7:25 PM
> To: Alastair D'Silva ; linuxppc-dev@lists.ozlabs.org
> Cc: linux-ker...@vger.kernel.org; linux-...@vger.kernel.org;
> mi...@neuling.org; vaib...@linux.vnet.ibm.com;
> aneesh.ku...@linux.vnet.ibm.com; ma...@
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi Linus,
Please pull some more powerpc fixes for 4.17:
The following changes since commit b2d7ecbe355698010a6b7a15eb179e09eb3d6a34:
powerpc/kvm/booke: Fix altivec related build break (2018-04-27 16:36:03 +1000)
are available in the git reposit
Currently memory is allocated for core-imc based on cpu_present_mask, which has
bit 'cpu' set iff cpu is populated. We use (cpu number / threads per core)
as as array index to access the memory.
So in a system with guarded cores, since allocation happens based on
cpu_present_mask, (cpu number / th
On Thu, May 03, 2018 at 10:29:29PM +1000, Michael Ellerman wrote:
> In the vmx AES init routines we do a printk(KERN_INFO ...) to report
> the fallback implementation we're using.
>
> However with a slow console this can significantly affect the speed of
> crypto operations. Using 'cryptsetup benc
On Thu, May 03, 2018 at 10:29:30PM +1000, Michael Ellerman wrote:
> In p8_aes_xts_init() we do a printk(KERN_INFO ...) to report the
> fallback implementation we're using. However with a slow console this
> can significantly affect the speed of crypto operations. So remove it.
>
> Fixes: c07f5d3da
> -Original Message-
> From: Yinbo Zhu [mailto:yinbo@nxp.com]
> Sent: Thursday, May 10, 2018 10:35 PM
> To: Yinbo Zhu ; Rob Herring ;
> Mark Rutland ; Catalin Marinas )
> ; Will Deacon ) ;
> Lorenzo Pieralisi ) ; Leo Li
> Cc: Xiaobo Xie ; Ran Wang ;
> Daniel Lezcano ; Thomas Gleixner
This patch series adds few improvements to the cxlflash driver and
it also contains couple of bug fixes.
This patch series is intended for 4.18 and is bisectable.
Matthew R. Ochs (1):
cxlflash: Use local mutex for AFU serialization
Uma Krishnan (6):
cxlflash: Yield to active send threads
c
The following Oops may be encountered if the device is reset, i.e. EEH
recovery, while there is heavy I/O traffic:
59:mon> t
[c000200db64bb680] c00809264c40 cxlflash_queuecommand+0x3b8/0x500
[cxlflash]
[c000200db64bb770] c090d3b0 scsi_dispatch_cm
The kernel log can get filled with debug messages from send_cmd_ioarrin()
when dynamic debug is enabled for the cxlflash module and there is a lot
of legacy I/O traffic.
While these messages are necessary to debug issues that involve command
tracking, the abundance of data can overwrite other usef
When a superpipe process that makes use of virtual LUNs is terminated or
killed abruptly, there is a possibility that the cxlflash driver could
hang and deprive other operations on the adapter.
The release fop registered to be invoked on a context close, detaches
every LUN associated with the cont
From: "Matthew R. Ochs"
AFUs can only process a single AFU command at a time. This is enforced
with a global mutex situated within the AFU send routine. As this mutex
has a global scope, it has the potential to unnecessarily block commands
destined for other AFUs.
Instead of using a global mutex
The new header file, backend.h, that was recently added is missing
the include guards. This commit adds the guards.
Signed-off-by: Uma Krishnan
---
drivers/scsi/cxlflash/backend.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/scsi/cxlflash/backend.h b/drivers/scsi/cxlflash/bac
As a staging cleanup to support transport specific builds of the cxlflash
module, relocate device dependent assignments to header files. This will
avoid littering the core driver with conditional compilation logic.
Signed-off-by: Uma Krishnan
---
drivers/scsi/cxlflash/main.c | 7 ++-
driver
Depending on the underlying transport, cxlflash has a dependency on either
the CXL or OCXL drivers, which are enabled via their Kconfig option.
Instead of having a module wide dependency on these config options, it is
better to isolate the object modules that are dependent on the CXL and OCXL
drive
On 5/9/18 7:59 AM, Christoph Hellwig wrote:
> Hi all,
>
> this series converts a few random block drivers to be highmem safe,
> in preparation of eventually getting rid of the block layer bounce
> buffering support.
Applied, thanks.
--
Jens Axboe
On Fri, 2018-05-11 at 19:13 +0530, Anju T Sudhakar wrote:
> Currently memory is allocated for core-imc based on cpu_present_mask, which
> has
> bit 'cpu' set iff cpu is populated. We use (cpu number / threads per core)
> as as array index to access the memory.
> So in a system with guarded cores,
On Fri, May 11, 2018 at 11:43 PM, Anju T Sudhakar
wrote:
> Currently memory is allocated for core-imc based on cpu_present_mask, which
> has
> bit 'cpu' set iff cpu is populated. We use (cpu number / threads per core)
> as as array index to access the memory.
> So in a system with guarded cores,
The exec_target binary could segfault calling _exit(2) because r13
is not set up properly (and libc looks at that when performing a
syscall). Call SYS_exit using syscall(2) which doesn't seem to
have this problem.
Signed-off-by: Nicholas Piggin
---
tools/testing/selftests/powerpc/benchmarks/exec
35 matches
Mail list logo
