[PATCH 06/18] crypto: talitos - fix ctr-aes-talitos

ctr-aes-talitos test fails as follows on SEC2 [0.837427] alg: skcipher: Test 1 failed (invalid result) on encryption for ctr-aes-talitos [0.845763] : 16 36 d5 ee 34 f8 06 25 d7 7f 8e 56 ca 88 43 45 [0.852345] 0010: f9 3f f7 17 2a b2 12 23 30 43 09 15 82 dd e1 97 [

Re: [PATCH] mm: deferred_init_memmap improvements

Hi Anshuman, Thank you very much for looking at this. My reply below:: On 10/06/2017 02:48 AM, Anshuman Khandual wrote: On 10/04/2017 08:59 PM, Pavel Tatashin wrote: This patch fixes another existing issue on systems that have holes in zones i.e CONFIG_HOLES_IN_ZONE is defined. In

linux-4.14-rc3/arch/powerpc/perf/imc-pmu.c:599: pointless test ?

Hello there, linux-4.14-rc3/arch/powerpc/perf/imc-pmu.c:599]: (style) Unsigned variable 'ncpu' can't be negative so it is unnecessary to test it. Source code is if (ncpu >= 0 && ncpu < nr_cpu_ids) { but unsigned int ncpu, core_id; Suggest remove test. Regards David Binderman

[PATCH 05/18] crypto: talitos - fix use of sg_link_tbl_len

sg_link_tbl_len shall be used instead of cryptlen, otherwise SECs which perform HW CICV verification will fail. Signed-off-by: Christophe Leroy --- drivers/crypto/talitos.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/crypto/talitos.c

[PATCH 12/18] crypto: talitos - don't check the number of channels at each interrupt

The number of channels is known from the beginning, no need to test it everytime. This patch defines two additional done functions handling only channel 0. Then the probe registers the correct one based on the number of channels. Signed-off-by: Christophe Leroy ---

[PATCH 10/18] crypto: talitos - use of_property_read_u32()

Use of_property_read_u32() to simplify DT read Signed-off-by: Christophe Leroy --- drivers/crypto/talitos.c | 21 + 1 file changed, 5 insertions(+), 16 deletions(-) diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c index

[PATCH 15/18] crypto: talitos - DMA map key in setkey()

dma_map_single() is an heavy operation which doesn't need to be done at each request as the key doesn't change. Instead of DMA mapping the key at every request, this patch maps it once in setkey() Signed-off-by: Christophe Leroy --- drivers/crypto/talitos.c | 56

[PATCH 08/18] crypto: talitos - declare local functions static

talitos_handle_buggy_hash() and talitos_sg_map() are only used locally, make them static Signed-off-by: Christophe Leroy --- drivers/crypto/talitos.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/crypto/talitos.c

[PATCH 16/18] crypto: talitos - do hw_context DMA mapping outside the requests

At every request, we map and unmap the same hash hw_context. This patch moves the dma mapping/unmapping in functions ahash_init() and ahash_import(). Signed-off-by: Christophe Leroy --- drivers/crypto/talitos.c | 80 ++-- 1

[PATCH 09/18] crypto: talitos - use devm_kmalloc()

Replace kmalloc() by devm_kmalloc() Signed-off-by: Christophe Leroy --- drivers/crypto/talitos.c | 30 -- 1 file changed, 12 insertions(+), 18 deletions(-) diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c index

[PATCH 14/18] crypto: talitos - simplify tests in ipsec_esp()

Do (desc->hdr & DESC_HDR_TYPE_IPSEC_ESP) only once. Limit number of if/else paths Signed-off-by: Christophe Leroy --- drivers/crypto/talitos.c | 42 -- 1 file changed, 20 insertions(+), 22 deletions(-) diff --git

[PATCH 13/18] crypto: talitos - remove to_talitos_ptr_len()

to_talitos_ptr() and to_talitos_ptr_len() are always called together in order to fully set a ptr, so lets merge them into a single helper. Signed-off-by: Christophe Leroy --- drivers/crypto/talitos.c | 56 ++-- 1 file changed,

[PATCH 18/18] crypto: talitos - avoid useless copy

This patch avoids copy of buffered data to hash from bufnext to buf Signed-off-by: Christophe Leroy --- drivers/crypto/talitos.c | 36 ++-- 1 file changed, 22 insertions(+), 14 deletions(-) diff --git a/drivers/crypto/talitos.c

[PATCH 11/18] crypto: talitos - use devm_ioremap()

Use devm_ioremap() Signed-off-by: Christophe Leroy --- drivers/crypto/talitos.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c index f139a0cef2e2..83b2a70a1ba7 100644 ---

[PATCH 17/18] crypto: talitos - chain in buffered data for ahash on SEC1

SEC1 doesn't support S/G in descriptors so for hash operations, the CPU has to build a buffer containing the buffered block and the incoming data. This generates a lot of memory copies which represents more than 50% of CPU time of a md5sum operation as shown below with a 'perf record'.

Re: [PATCH v10 05/10] mm: zero reserved and unavailable struct pages

Hi Michal, As I've said in other reply this should go in only if the scenario you describe is real. I am somehow suspicious to be honest. I simply do not see how those weird struct pages would be in a valid pfn range of any zone. There are examples of both when unavailable memory is not

[PATCH 07/18] crypto: talitos - zeroize the descriptor with memset()

This patch zeroize the descriptor at allocation using memset(). This has two advantages: - It reduces the number of places where data has to be set to 0 - It avoids reading memory and loading the cache with data that will be entirely replaced. Signed-off-by: Christophe Leroy

Re: [PATCH v3 0/3] Split default display handling out from VGA arbiter

On Wed, Sep 27, 2017 at 01:52:55PM +1000, Daniel Axtens wrote: > Hi Bjorn, > > Yes, this works: > > Tested-by: Daniel Axtens # arm64, ppc64-qemu-tcg I guess I was assuming you'd pick this up, but that doesn't really make sense because I didn't give you a signed-off-by or

[PATCH 2/2] vgaarb: Factor out EFI and fallback default device selection

From: Bjorn Helgaas The default VGA device is normally set in vga_arbiter_add_pci_device() when we call it for the first enabled device that can be accessed with the legacy VGA resources ([mem 0xa-0xb], etc.) That default device can be overridden by an EFI device

Re: [RFC PATCH for 4.14 1/2] membarrier: Remove unused code for architectures without membarrier hooks

On Thu, Oct 05, 2017 at 06:33:26PM -0400, Mathieu Desnoyers wrote: > Architectures without membarrier hooks don't need to emit the > empty membarrier_arch_switch_mm() static inline when > CONFIG_MEMBARRIER=y. > > Adapt the CONFIG_MEMBARRIER=n counterpart to only emit the empty >

Re: [RFC PATCH for 4.14 1/2] membarrier: Remove unused code for architectures without membarrier hooks

- On Oct 6, 2017, at 5:08 PM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: > On Thu, Oct 05, 2017 at 06:33:26PM -0400, Mathieu Desnoyers wrote: >> Architectures without membarrier hooks don't need to emit the >> empty membarrier_arch_switch_mm() static inline when >>

[PATCH 1/2] vgaarb: Select a default VGA device even if there's no legacy VGA

From: Bjorn Helgaas Daniel Axtens reported that on the HiSilicon D05 board, the VGA device is behind a bridge that doesn't support PCI_BRIDGE_CTL_VGA, so the VGA arbiter never selects it as the default, which means Xorg auto-detection doesn't work. VGA is a legacy PCI

Re: [PATCH0/8] Support for ibm, dynamic-memory-v2 device tree property

Nathan Fontenot writes: > This patch set provides a set of updates to de-couple the LMB information > provided in the ibm,dynamic-memory device tree property from the device > tree property format. The goal is to provide a data set of LMB information > so that consumners

[PATCH 0/2] vgaarb: Select fallback default VGA device

These patches are supposed to fix a problem Daniel Axtens found on the HiSilicon D05 board. The VGA device there is behind a bridge that doesn't support PCI_BRIDGE_CTL_VGA, so the arbiter never selects the device as the default. The first patch extends the arbiter so that if it can't find an

[PATCH v2 01/18] powerpc/vas: init missing fields from [rt]xattr

Initialize a few missing window context fields from the window attributes specified by the caller. These fields are currently set to their default values by the caller (NX-842), but would be good to apply them anyway. Signed-off-by: Sukadev Bhattiprolu ---

[PATCH v2 09/18] powerpc/vas: Create cpu to vas id mapping

Create a cpu to vasid mapping so callers can specify -1 instead of trying to find a VAS id. Changelog[v2] [Michael Ellerman] Use per-cpu variables to simplify code. Signed-off-by: Sukadev Bhattiprolu --- arch/powerpc/platforms/powernv/vas.c | 14

[PATCH v2 08/18] powerpc/vas: poll for return of window credits

Normally, the NX driver waits for the CRBs to be processed before closing the window. But it is better to ensure that the credits are returned before the window gets reassigned later. Signed-off-by: Sukadev Bhattiprolu --- arch/powerpc/platforms/powernv/vas-window.c

[PATCH v2 11/18] powerpc/vas: Export HVWC to debugfs

Export the VAS Window context information to debugfs. We need to hold a mutex when closing the window to prevent a race with the debugfs read(). Rather than introduce a per-instance mutex, we use the global vas_mutex for now, since it is not heavily contended. The window->cop field is only

[PATCH v2 10/18] powerpc/vas, nx-842: Define and use chip_to_vas_id()

Define a helper, chip_to_vas_id() to map a given chip id to corresponding vas id. Normally, callers of vas_rx_win_open() and vas_tx_win_open() want the VAS window to be on the same chip where the calling thread is executing. These callers can pass in -1 for the VAS id. This interface will be

[PATCH v2 15/18] powerpc: Emulate paste instruction

From: Michael Neuling On POWER9 DD2.1 and below there are issues when the paste instruction generates an error. If an error occurs when thread reconfiguration happens (ie another thread in the core goes into/out of powersave) the core may hang. To avoid this a special

[PATCH v2 16/18] powerpc/vas: Define vas_win_paste_addr()

Define an interface that the NX drivers can use to find the physical paste address of a send window. This interface is expected to be used with the mmap() operation of the NX driver's device. i.e the user space process can use driver's mmap() operation to map the send window's paste address into

[PATCH v2 00/18] powerpc/vas: Add support for FTW

The first 10 patches in this set were posted earlier[1] and don't have any significant changes since then. This set sanitizes cpu/chip id to VAS id mapping, improves vas_win_close() performance and adds a check for return of credits and cleans up some code. Patch 11 adds debugfs support for the

[PATCH v2 02/18] powerpc/vas: Validate window credits

NX-842, the only user of VAS, sets the window credits to default values but VAS should check the credits against the possible max values. The VAS_WCREDS_MIN is not needed and can be dropped. Signed-off-by: Sukadev Bhattiprolu ---

[PATCH v2 05/18] powerpc/vas: Use helper to unpin/close window

Use a helper to have the hardware unpin and mark a window closed. Signed-off-by: Sukadev Bhattiprolu --- arch/powerpc/platforms/powernv/vas-window.c | 22 +++--- 1 file changed, 15 insertions(+), 7 deletions(-) diff --git

[PATCH v2 06/18] powerpc/vas: Reduce polling interval for busy state

A VAS window is normally in "busy" state for only a short duration. Reduce the time we wait for the window to go to "not-busy" state to speed-up vas_win_close() a bit. Signed-off-by: Sukadev Bhattiprolu --- arch/powerpc/platforms/powernv/vas-window.c | 10 ++

[PATCH v2 07/18] powerpc/vas: Save configured window credits

Save the configured max window credits for a window in the vas_window structure. We will need this when polling for return of window credits. Signed-off-by: Sukadev Bhattiprolu --- arch/powerpc/platforms/powernv/vas-window.c | 6 --

[PATCH v2 13/18] powerpc: Add support for setting SPRN_TIDR

We need the SPRN_TIDR to be set for use with fast thread-wakeup (core- to-core wakeup) and also with CAPI. Each thread in a process needs to have a unique id within the process. But as explained below, for now, we assign globally unique thread ids to all threads in the system. Signed-off-by:

[PATCH v2 12/18] powerpc: have copy depend on CONFIG_BOOK3S_64

Have the COPY/PASTE instructions depend on CONFIG_BOOK3S_64 rather than CONFIG_PPC_STD_MMU_64. Signed-off-by: Sukadev Bhattiprolu --- arch/powerpc/kernel/process.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/kernel/process.c

[PATCH v2 14/18] powerpc: Define set_thread_used_vas()

A CP_ABORT instruction is required in processes that have mapped a VAS "paste address" with the intention of using COPY/PASTE instructions. But since CP_ABORT is expensive, we want to restrict it to only processes that use/intend to use COPY/PASTE. Define an interface, set_thread_used_vas(), that

[PATCH v2 04/18] powerpc/vas: Drop poll_window_cast_out().

Polling for window cast out is listed in the spec, but turns out that it is not strictly necessary and slows down window close. Making it a stub for now. Signed-off-by: Sukadev Bhattiprolu --- arch/powerpc/platforms/powernv/vas-window.c | 34

[PATCH v2 03/18] powerpc/vas: Cleanup some debug code

Clean up vas.h and the debug code around ifdef vas_debug. Signed-off-by: Sukadev Bhattiprolu --- arch/powerpc/platforms/powernv/vas-window.c | 8 +++-- arch/powerpc/platforms/powernv/vas.h| 56 +++-- 2 files changed, 18 insertions(+),

[PATCH v2 17/18] powerpc/vas: Define vas_win_id()

Define an interface to return a system-wide unique id for a given VAS window. The vas_win_id() will be used in a follow-on patch to generate an unique handle for a user space receive window. Applications can use this handle to pair send and receive windows for fast thread-wakeup. The hardware

[PATCH v2 18/18] powerpc/vas: Add support for user receive window

Add support for user space receive window (for the Fast thread-wakeup coprocessor type) Signed-off-by: Sukadev Bhattiprolu --- arch/powerpc/platforms/powernv/vas-window.c | 59 + 1 file changed, 52 insertions(+), 7 deletions(-) diff --git

[PATCH 1/3] powerpc/tm: Add commandline option to disable hardware transactional memory

Currently the kernel relies on firmware to inform it whether or not the CPU supports HTM and as long as the kernel was built with CONFIG_PPC_TRANSACTIONAL_MEM=y then it will allow userspace to make use of the facility. There may be situations where it would be advantageous for the kernel to not

[PATCH 3/3] powerpc/tm: P9 disable transactionally suspended sigcontexts

From: Michael Neuling Unfortunately userspace can construct a sigcontext which enables suspend. Thus userspace can force Linux into a path where trechkpt is executed. This patch blocks this from happening on POWER9 but sanity checking sigcontexts passed in. ptrace doesn't

[PATCH 0/3] some boot/shutdown improvements

Hi, These are a couple of improvements to powernv/opal boot and shutdown paths. Also a patch to move smp_send_stop over to use NMI IPIs, which gives us a significantly better chance to stop secondaries on platforms which support it (pSeries and PowerNV POWER9 so far). Patch 1 in particular it

[PATCH 3/3] powerpc: use NMI IPI for smp_send_stop

Use the NMI IPI rather than smp_call_function for smp_send_stop. Have stopped CPUs hard disable interrupts rather than just soft disable. This function is used in crash/panic/shutdown paths to bring other CPUs down as quickly and reliably as possible, and minimizing their potential to cause

[PATCH] cpufreq: powernv: Return the actual CPU frequency in /proc/cpuinfo

Make /proc/cpuinfo read the frequency of the CPU it is running at instead of reading the cached value of the last requested frequency. In conditions like WOF/throttle CPU can be running at a different frequency than the requested frequency. Signed-off-by: Shriya ---

[PATCH 1/3] powerpc/powernv: Avoid the secondary hold spinloop for OPAL boot

OPAL boot does not insert secondaries at 0x60 to wait at the secondary hold spinloop. Instead it keeps them held in firmware until the opal_start_cpu call is made, which directs them where the caller specifies. Linux inserts them into generic_secondary_smp_init(), which is after the secondary hold

Re: [PATCH] mm: deferred_init_memmap improvements

On 10/04/2017 08:59 PM, Pavel Tatashin wrote: > This patch fixes another existing issue on systems that have holes in > zones i.e CONFIG_HOLES_IN_ZONE is defined. > > In for_each_mem_pfn_range() we have code like this: > > if (!pfn_valid_within(pfn) > goto free_range; > > Note: 'page' is

Re: [PATCH tip/core/rcu 1/3] membarrier: Provide register expedited private command

> AFAIU the scheduler rq->lock is held while preemption is disabled. > synchronize_sched() is used here to ensure that all pre-existing > preempt-off critical sections have completed. > > So saying that we use synchronize_sched() to synchronize with rq->lock > would be stretching the truth a bit.

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

On 2017/09/18 09:23AM, Santosh Sivaraj wrote: > 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

Re: [PATCH 3/3] powerpc/tm: P9 disable transactionally suspended sigcontexts

On Fri, 2017-10-06 at 18:46 +1100, Cyril Bur wrote: > From: Michael Neuling > > Unfortunately userspace can construct a sigcontext which enables > suspend. Thus userspace can force Linux into a path where trechkpt is > executed. > > This patch blocks this from happening on

Re: [PATCH 1/2] powerpc/vdso64: Coarse timer support preparatory patch

Hi Santosh, On 2017/09/18 09:23AM, Santosh Sivaraj wrote: > Reorganize code to make it easy to introduce CLOCK_REALTIME_COARSE and > CLOCK_MONOTONIC_COARSE timer support. > > Signed-off-by: Santosh Sivaraj > --- > arch/powerpc/kernel/vdso64/gettimeofday.S | 14

Re: [PATCH v10 09/10] mm: stop zeroing memory during allocation in vmemmap

On Fri 06-10-17 11:10:14, David Laight wrote: > From: Pavel Tatashin > > Sent: 05 October 2017 22:11 > > 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. >

RE: [PATCH v10 09/10] mm: stop zeroing memory during allocation in vmemmap

From: Michal Hocko > Sent: 06 October 2017 12:47 > On Fri 06-10-17 11:10:14, David Laight wrote: > > From: Pavel Tatashin > > > Sent: 05 October 2017 22:11 > > > vmemmap_alloc_block() will no longer zero the block, so zero memory > > > at its call sites for everything except struct pages. Struct

Re: [PATCH v10 09/10] mm: stop zeroing memory during allocation in vmemmap

On Fri 06-10-17 12:11:42, David Laight wrote: > From: Michal Hocko > > Sent: 06 October 2017 12:47 > > On Fri 06-10-17 11:10:14, David Laight wrote: > > > From: Pavel Tatashin > > > > Sent: 05 October 2017 22:11 > > > > vmemmap_alloc_block() will no longer zero the block, so zero memory > > > > at

Re: [PATCH 2/4] PCI: Remove redundant pci_dev, pci_bus, resource declarations

On Thu, Oct 05, 2017 at 03:38:49PM -0500, Bjorn Helgaas wrote: > From: Bjorn Helgaas > > defines struct pci_bus and struct pci_dev and includes the > struct resource definition before including . Nobody includes > directly, so they don't need their own declarations. > >

Re: [PATCH 1/4] PCI: Remove redundant pcibios_set_master() declarations

On Thu, Oct 05, 2017 at 03:38:42PM -0500, Bjorn Helgaas wrote: > From: Bjorn Helgaas > > All users of pcibios_set_master() include , which already has > a declaration. Remove the unnecessary declarations from the > files. > > Signed-off-by: Bjorn Helgaas

[PATCH 2/3] powerpc/tm: P9 disabled suspend mode workaround

[from Michael Neulings original patch] Each POWER9 core is made of two super slices. Each super slice can only have one thread at a time in TM suspend mode. The super slice restricts ever entering a state where both threads are in suspend by aborting transactions on tsuspend or exceptions into the

Re: Possible LMB hot unplug bug in 4.13+ kernels

Unless you (Daniel) think there's some reason lmb_is_removable() is incorrectly returning false. But most likely it's correct and there's just an unmovable allocation in that range. I am not educated enough to say that the current behavior is wrong. What I can say is that in 4.11 and older

[GIT PULL] Please pull powerpc/linux.git powerpc-4.14-4 tag

Hi Linus, Please pull some more powerpc fixes for 4.14. This is two weeks worth of fixes, and the diffstat is reasonably small, so I think we're on track. The following changes since commit e19b205be43d11bff638cad4487008c48d21c103: Linux 4.14-rc2 (2017-09-24 16:38:56 -0700) are available in

Re: powerpc/powernv: Increase memory block size to 1GB on radix

On Thu, 2017-09-07 at 05:05:51 UTC, Anton Blanchard wrote: > From: Anton Blanchard > > Memory hot unplug on PowerNV radix hosts is broken. Our memory block > size is 256MB but since we map the linear region with very large pages, > each pte we tear down maps 1GB. > > A hot

RE: [PATCH v10 09/10] mm: stop zeroing memory during allocation in vmemmap

From: Pavel Tatashin > Sent: 05 October 2017 22:11 > 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. It seems dangerous to change an allocator to stop zeroing

Re: [PATCH 3/3] powerpc/tm: P9 disable transactionally suspended sigcontexts

Hi Cyril, On 06-10-2017 04:46, Cyril Bur wrote: > From: Michael Neuling > > Unfortunately userspace can construct a sigcontext which enables > suspend. Thus userspace can force Linux into a path where trechkpt is > executed. > > This patch blocks this from happening on

Re: [PATCH] cpufreq: powernv: Return the actual CPU frequency in /proc/cpuinfo

On 2017-10-06 16:00, Michael Ellerman wrote: Shriya writes: Make /proc/cpuinfo read the frequency of the CPU it is running at instead of reading the cached value of the last requested frequency. In conditions like WOF/throttle CPU can be running at a different

Re: [PATCH 2/3] powerpc/tm: P9 disabled suspend mode workaround

Hi Cyril, On 06-10-2017 04:46, Cyril Bur wrote: > [added by Cyril Bur] > As the no-suspend firmware change is novel and untested using it should > be opt in by users. Furthumore, currently the kernel has no method to I forgot to mention on my last reply, but should s/Furthumore/Furthermore/ ?

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

On 2017/09/18 09:23AM, Santosh Sivaraj wrote: > 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

[PATCH 2/3] powerpc/powernv: Always stop secondaries before reboot/shutdown

Currently powernv reboot and shutdown requests just leave secondaries to do their own things. This is undesirable because they can trigger any number of watchdogs while waiting for reboot, but also we don't know what else they might be doing, or they might be stuck somewhere causing trouble. The

Re: [PATCH 2/3] powerpc/tm: P9 disabled suspend mode workaround

Benjamin Herrenschmidt writes: > On Fri, 2017-10-06 at 18:46 +1100, Cyril Bur wrote: ... >> diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c >> index 760872916013..2cb01b48123a 100644 >> --- a/arch/powerpc/kernel/cputable.c >> +++

Re: [PATCH 1/2] powerpc/vdso64: Coarse timer support preparatory patch

Thanks for reviewing Naveen. "Naveen N. Rao" writes: > On 2017/09/18 09:23AM, Santosh Sivaraj wrote: >> diff --git a/arch/powerpc/kernel/vdso64/gettimeofday.S >> b/arch/powerpc/kernel/vdso64/gettimeofday.S >> index 382021324883..a0b4943811db 100644 >> ---

Re: [PATCH] cpufreq: powernv: Return the actual CPU frequency in /proc/cpuinfo

Shriya writes: > Make /proc/cpuinfo read the frequency of the CPU it is running at > instead of reading the cached value of the last requested frequency. > In conditions like WOF/throttle CPU can be running at a different > frequency than the requested frequency.

Re: [PATCH 2/3] powerpc/tm: P9 disabled suspend mode workaround

On Fri, 2017-10-06 at 18:46 +1100, Cyril Bur wrote: > [from Michael Neulings original patch] > Each POWER9 core is made of two super slices. Each super slice can > only have one thread at a time in TM suspend mode. The super slice > restricts ever entering a state where both threads are in suspend

Re: [PATCH v10 05/10] mm: zero reserved and unavailable struct pages

On Thu 05-10-17 17:11:19, Pavel Tatashin wrote: > Some memory is reserved but unavailable: not present in memblock.memory > (because not backed by physical pages), but present in memblock.reserved. > Such memory has backing struct pages, but they are not initialized by going > through

[PATCH 00/18] crypto: talitos - fixes and performance improvement

This serie fixes and improves the talitos crypto driver. First 6 patchs are fixes of failures reported by the new tests in the kernel crypto test manager. The 8 following patches are cleanups and simplifications. The last 4 ones are performance improvement. The main improvement is in the one

[PATCH 01/18] crypto: talitos - fix AEAD test failures

AEAD tests fail when destination SG list has more than 1 element. [2.058752] alg: aead: Test 1 failed on encryption for authenc-hmac-sha1-cbc-aes-talitos [2.066965] : 53 69 6e 67 6c 65 20 62 6c 6f 63 6b 20 6d 73 67 0010: c0 43 ff 74 c0 43 ff e0 de 83 d1 20 de 84 8e 54

[PATCH 02/18] crypto: talitos - fix memory corruption on SEC2

On SEC2, when using the old descriptors type (hmac snoop no afeu) for doing IPsec, the CICV out pointeur points out of the allocated memory. [2.502554] = [2.510740] BUG dma-kmalloc-256 (Not tainted): Redzone

[PATCH 03/18] crypto: talitos - fix setkey to check key weakness

Crypto manager test report the following failures: [3.061081] alg: skcipher: setkey failed on test 5 for ecb-des-talitos: flags=100 [3.069342] alg: skcipher-ddst: setkey failed on test 5 for ecb-des-talitos: flags=100 [3.077754] alg: skcipher-ddst: setkey failed on test 5 for

[PATCH 04/18] crypto: talitos - fix AEAD for sha224 on non sha224 capable chips

sha224 AEAD test fails with: [2.803125] talitos ff02.crypto: DEUISR 0x_ [2.808743] talitos ff02.crypto: MDEUISR 0x8010_ [2.814678] talitos ff02.crypto: DESCBUF 0x20731f21_0018 [2.820616] talitos ff02.crypto: DESCBUF