Re: [PATCH] treewide: remove duplicate includes

Hello, On Mon, Dec 04, 2017 at 03:19:39AM +0530, Pravin Shedge wrote: > diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c > index d04ec3b..e09f035 100644 > --- a/drivers/thermal/of-thermal.c > +++ b/drivers/thermal/of-thermal.c > @@ -30,7 +30,6 @@ > #include > #include

Re: [PATCH] treewide: remove duplicate includes

On Mon, Dec 04, 2017 at 03:19:39AM +0530, Pravin Shedge wrote: > These duplicate includes have been found with scripts/checkincludes.pl but > they have been removed manually to avoid removing false positives. > > Unit Testing: > > - build successful > - LTP testsuite passes. > - checkpatch.pl

Re: [PATCH v3 1/3] dt-bindings: hwrng: Add Samsung Exynos 5250+ True RNG bindings

On Mon, Dec 04, 2017 at 01:53:49PM +0100, Łukasz Stelmach wrote: > Add binding documentation for the True Random Number Generator > found on Samsung Exynos 5250+ SoCs. > > Signed-off-by: Łukasz Stelmach > --- > .../devicetree/bindings/rng/samsung,exynos5250-trng.txt | 17

[Part2 PATCH v9 11/38] crypto: ccp: Define SEV key management command id

Define Secure Encrypted Virtualization (SEV) key management command id and structure. The command definition is available in SEV KM spec 0.14 (http://support.amd.com/TechDocs/55766_SEV-KM API_Specification.pdf) Cc: Paolo Bonzini Cc: "Radim Krčmář" Cc:

[Part2 PATCH v9 00/38] x86: Secure Encrypted Virtualization (AMD)

This part of Secure Encrypted Virtualization (SEV) patch series focuses on KVM changes required to create and manage SEV guests. SEV is an extension to the AMD-V architecture which supports running encrypted virtual machine (VMs) under the control of a hypervisor. Encrypted VMs have their pages

[Part2 PATCH v9 12/38] crypto: ccp: Add Platform Security Processor (PSP) device support

The Platform Security Processor (PSP) is part of the AMD Secure Processor (AMD-SP) functionality. The PSP is a dedicated processor that provides support for key management commands in Secure Encrypted Virtualization (SEV) mode, along with software-based Trusted Execution Environment (TEE) to

[Part2 PATCH v9 14/38] crypto: ccp: Implement SEV_FACTORY_RESET ioctl command

The SEV_FACTORY_RESET command can be used by the platform owner to reset the non-volatile SEV related data. The command is defined in SEV spec section 5.4 Cc: Paolo Bonzini Cc: "Radim Krčmář" Cc: Borislav Petkov Cc: Herbert Xu

[Part2 PATCH v9 15/38] crypto: ccp: Implement SEV_PLATFORM_STATUS ioctl command

The SEV_PLATFORM_STATUS command can be used by the platform owner to get the current status of the platform. The command is defined in SEV spec section 5.5. Cc: Paolo Bonzini Cc: "Radim Krčmář" Cc: Borislav Petkov Cc: Herbert Xu

[Part2 PATCH v9 13/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support

AMD's new Secure Encrypted Virtualization (SEV) feature allows the memory contents of virtual machines to be transparently encrypted with a key unique to the VM. The programming and management of the encryption keys are handled by the AMD Secure Processor (AMD-SP) which exposes the commands for

[Part2 PATCH v9 10/38] crypto: ccp: Define SEV userspace ioctl and command id

Add a include file which defines the ioctl and command id used for issuing SEV platform management specific commands. Cc: Paolo Bonzini Cc: "Radim Krčmář" Cc: Borislav Petkov Cc: Herbert Xu Cc: Gary Hook

[Part2 PATCH v9 19/38] crypto: ccp: Implement SEV_PEK_CERT_IMPORT ioctl command

The SEV_PEK_CERT_IMPORT command can be used to import the signed PEK certificate. The command is defined in SEV spec section 5.8. Cc: Paolo Bonzini Cc: "Radim Krčmář" Cc: Borislav Petkov Cc: Herbert Xu Cc:

[Part2 PATCH v9 17/38] crypto: ccp: Implement SEV_PDH_GEN ioctl command

The SEV_PDH_GEN command is used to re-generate the Platform Diffie-Hellman (PDH) key. The command is defined in SEV spec section 5.6. Cc: Paolo Bonzini Cc: "Radim Krčmář" Cc: Borislav Petkov Cc: Herbert Xu Cc:

[Part2 PATCH v9 09/38] crypto: ccp: Build the AMD secure processor driver only with AMD CPU support

From: Borislav Petkov This is AMD-specific hardware so present it in Kconfig only when AMD CPU support is enabled or on ARM64 where it is also used. Signed-off-by: Borislav Petkov Signed-off-by: Brijesh Singh Reviewed-by: Gary R Hook

[Part2 PATCH v9 16/38] crypto: ccp: Implement SEV_PEK_GEN ioctl command

The SEV_PEK_GEN command is used to generate a new Platform Endorsement Key (PEK). The command is defined in SEV spec section 5.6. Cc: Paolo Bonzini Cc: "Radim Krčmář" Cc: Borislav Petkov Cc: Herbert Xu Cc:

[Part2 PATCH v9 20/38] crypto: ccp: Implement SEV_PDH_CERT_EXPORT ioctl command

The SEV_PDH_CERT_EXPORT command can be used to export the PDH and its certificate chain. The command is defined in SEV spec section 5.10. Cc: Paolo Bonzini Cc: "Radim Krčmář" Cc: Borislav Petkov Cc: Herbert Xu

[Part2 PATCH v9 18/38] crypto: ccp: Implement SEV_PEK_CSR ioctl command

The SEV_PEK_CSR command can be used to generate a PEK certificate signing request. The command is defined in SEV spec section 5.7. Cc: Paolo Bonzini Cc: "Radim Krčmář" Cc: Borislav Petkov Cc: Herbert Xu Cc:

[PATCH 02/45] drivers: crypto: remove duplicate includes

These duplicate includes have been found with scripts/checkincludes.pl but they have been removed manually to avoid removing false positives. Signed-off-by: Pravin Shedge --- drivers/crypto/bcm/cipher.c | 1 -

Re: [PATCH 0/5] crypto: arm64 - disable NEON across scatterwalk API calls

On 2 December 2017 at 13:59, Peter Zijlstra wrote: > On Sat, Dec 02, 2017 at 11:15:14AM +, Ard Biesheuvel wrote: >> On 2 December 2017 at 09:11, Ard Biesheuvel >> wrote: > >> > They consume the entire input in a single go, yes. But making it

Re: [PATCH 01/10] staging: ccree: remove inline qualifiers

On Sun, Dec 03, 2017 at 01:58:12PM +, Gilad Ben-Yossef wrote: > The ccree drivers was marking a lot of big functions in C file as > static inline for no good reason. Remove the inline qualifier from > any but the few truly single line functions. > The compiler is free to ignore inline

Re: [PATCH 00/10] staging: ccree: cleanups & fixes

Looks good. Thanks! regards, dan carpenter

Re: [PATCH v3 1/3] dt-bindings: hwrng: Add Samsung Exynos 5250+ True RNG bindings

On Mon, Dec 4, 2017 at 1:53 PM, Łukasz Stelmach wrote: > Add binding documentation for the True Random Number Generator > found on Samsung Exynos 5250+ SoCs. > > Signed-off-by: Łukasz Stelmach > --- >

[PATCH v2 05/19] crypto: arm64/chacha20 - move kernel mode neon en/disable into loop

When kernel mode NEON was first introduced on arm64, the preserve and restore of the userland NEON state was completely unoptimized, and involved saving all registers on each call to kernel_neon_begin(), and restoring them on each call to kernel_neon_end(). For this reason, the NEON crypto code

[PATCH v2 04/19] crypto: arm64/aes-bs - move kernel mode neon en/disable into loop

When kernel mode NEON was first introduced on arm64, the preserve and restore of the userland NEON state was completely unoptimized, and involved saving all registers on each call to kernel_neon_begin(), and restoring them on each call to kernel_neon_end(). For this reason, the NEON crypto code

[PATCH v2 01/19] crypto: testmgr - add a new test case for CRC-T10DIF

In order to be able to test yield support under preempt, add a test vector for CRC-T10DIF that is long enough to take multiple iterations (and thus possible preemption between them) of the primary loop of the accelerated x86 and arm64 implementations. Signed-off-by: Ard Biesheuvel

[PATCH v2 17/19] crypto: arm64/crc32-ce - yield NEON every 16 blocks of input

Avoid excessive scheduling delays under a preemptible kernel by yielding the NEON every 16 blocks of input. Signed-off-by: Ard Biesheuvel --- arch/arm64/crypto/crc32-ce-core.S | 55 +++- 1 file changed, 43 insertions(+), 12 deletions(-) diff --git

[PATCH v2 15/19] crypto: arm64/aes-bs - yield after processing each 128 bytes of input

Currently, the bit-sliced AES code may keep preemption disabled for as long as it takes to process each contigous chunk of input, which could be as large as a page or skb, depending on the context. For this code to be useable in RT context, it needs to operate on fixed chunks of limited size. So

[PATCH v2 14/19] crypto: arm64/aes-blk - yield after processing a fixed chunk of input

Currently, the AES block code may keep preemption disabled for as long as it takes to process each contigous chunk of input, which could be as large as a page or skb, depending on the context. For this code to be useable in RT context, it needs to operate on fixed chunks of limited size. So let's

[PATCH v2 13/19] crypto: arm64/sha2-ce - yield every 8 blocks of input

Avoid excessive scheduling delays under a preemptible kernel by yielding the NEON every 8 blocks of input. Signed-off-by: Ard Biesheuvel --- arch/arm64/crypto/sha2-ce-core.S | 40 ++-- 1 file changed, 29 insertions(+), 11 deletions(-) diff --git

[PATCH v2 07/19] crypto: arm64/aes-blk - remove configurable interleave

The AES block mode implementation using Crypto Extensions or plain NEON was written before real hardware existed, and so its interleave factor was made build time configurable (as well as an option to instantiate all interleaved sequences inline rather than as subroutines) We ended up using

[PATCH v2 12/19] crypto: arm64/sha1-ce - yield every 8 blocks of input

Avoid excessive scheduling delays under a preemptible kernel by yielding the NEON every 8 blocks of input. Signed-off-by: Ard Biesheuvel --- arch/arm64/crypto/sha1-ce-core.S | 45 ++-- 1 file changed, 32 insertions(+), 13 deletions(-) diff --git

[PATCH v2 03/19] crypto: arm64/aes-blk - move kernel mode neon en/disable into loop

When kernel mode NEON was first introduced on arm64, the preserve and restore of the userland NEON state was completely unoptimized, and involved saving all registers on each call to kernel_neon_begin(), and restoring them on each call to kernel_neon_end(). For this reason, the NEON crypto code

[PATCH v2 06/19] crypto: arm64/ghash - move kernel mode neon en/disable into loop

When kernel mode NEON was first introduced on arm64, the preserve and restore of the userland NEON state was completely unoptimized, and involved saving all registers on each call to kernel_neon_begin(), and restoring them on each call to kernel_neon_end(). For this reason, the NEON crypto code

[PATCH v2 00/19] crypto: arm64 - play nice with CONFIG_PREEMPT

This is a followup 'crypto: arm64 - disable NEON across scatterwalk API calls' sent out last Friday. As reported by Sebastian, the way the arm64 NEON crypto code currently keeps kernel mode NEON enabled across calls into skcipher_walk_xxx() is causing problems with RT builds, given that the

[PATCH v2 02/19] crypto: arm64/aes-ce-ccm - move kernel mode neon en/disable into loop

When kernel mode NEON was first introduced on arm64, the preserve and restore of the userland NEON state was completely unoptimized, and involved saving all registers on each call to kernel_neon_begin(), and restoring them on each call to kernel_neon_end(). For this reason, the NEON crypto code

[PATCH v2 11/19] arm64: assembler: add macro to conditionally yield the NEON under PREEMPT

Add a support macro to conditionally yield the NEON (and thus the CPU) that may be called from the assembler code. Given that especially the instruction based accelerated crypto code may use very tight loops, add some parametrization so that the TIF_NEED_RESCHED flag test is only executed every so

[PATCH v3 1/3] dt-bindings: hwrng: Add Samsung Exynos 5250+ True RNG bindings

Add binding documentation for the True Random Number Generator found on Samsung Exynos 5250+ SoCs. Signed-off-by: Łukasz Stelmach --- .../devicetree/bindings/rng/samsung,exynos5250-trng.txt | 17 + 1 file changed, 17 insertions(+) create mode 100644

[PATCH v3 0/3] True RNG driver for Samsung Exynos 5250+ SoCs

Hello. The following patches add support for the true random number generator found in Samsung Exynos 5250+ SoCs. Patch #1 adds documentation for devicetree bindings. Patch #2 introduces the driver and appropriate changes in Makefile and Kconfig. Patch #3 adds nodes in devicetree files for

Re: [PATCH v3 2/3] hwrng: exynos - add Samsung Exynos True RNG driver

On Mon, Dec 4, 2017 at 1:53 PM, Łukasz Stelmach wrote: > Add support for True Random Number Generator found in Samsung Exynos > 5250+ SoCs. > > Signed-off-by: Łukasz Stelmach > --- > MAINTAINERS | 7 + >

[bug report] chcr: Add support for Inline IPSec

Hello Atul Gupta, The patch 6dad4e8ab3ec: "chcr: Add support for Inline IPSec" from Nov 16, 2017, leads to the following static checker warning: drivers/crypto/chelsio/chcr_ipsec.c:431 copy_key_cpltx_pktxt() warn: potential pointer math issue ('q->q.desc' is a 512 bit pointer)

[PATCH v2 09/19] crypto: arm64/aes-blk - add 4 way interleave to CBC-MAC encrypt path

CBC MAC is strictly sequential, and so the current AES code simply processes the input one block at a time. However, we are about to add yield support, which adds a bit of overhead, and which we prefer to align with other modes in terms of granularity (i.e., it is better to have all routines yield

[PATCH v2 19/19] DO NOT MERGE

Test code to force a kernel_neon_end+begin sequence at every yield point, and wipe the entire NEON state before resuming the algorithm. --- arch/arm64/include/asm/assembler.h | 33 1 file changed, 33 insertions(+) diff --git a/arch/arm64/include/asm/assembler.h

[PATCH v2 10/19] crypto: arm64/sha256-neon - play nice with CONFIG_PREEMPT kernels

Tweak the SHA256 update routines to invoke the SHA256 block transform block by block, to avoid excessive scheduling delays caused by the NEON algorithm running with preemption disabled. Also, remove a stale comment which no longer applies now that kernel mode NEON is actually disallowed in some

[PATCH v2 16/19] crypto: arm64/aes-ghash - yield after processing fixed number of blocks

This updates both the core GHASH as well as the AES-GCM algorithm to yield each time after processing a fixed chunk of input. For the GCM driver, we align with the other AES/CE block mode drivers, and use a block size of 64 bytes. The core GHASH is much shorter, so let's use a block size of 128

[PATCH v2 08/19] crypto: arm64/aes-blk - add 4 way interleave to CBC encrypt path

CBC encryption is strictly sequential, and so the current AES code simply processes the input one block at a time. However, we are about to add yield support, which adds a bit of overhead, and which we prefer to align with other modes in terms of granularity (i.e., it is better to have all

[PATCH v2 18/19] crypto: arm64/crct10dif-ce - yield NEON every 8 blocks of input

Avoid excessive scheduling delays under a preemptible kernel by yielding the NEON every 8 blocks of input. Signed-off-by: Ard Biesheuvel --- arch/arm64/crypto/crct10dif-ce-core.S | 39 ++-- 1 file changed, 35 insertions(+), 4 deletions(-) diff --git

[PATCH v3 2/3] hwrng: exynos - add Samsung Exynos True RNG driver

Add support for True Random Number Generator found in Samsung Exynos 5250+ SoCs. Signed-off-by: Łukasz Stelmach --- MAINTAINERS | 7 + drivers/char/hw_random/Kconfig | 12 ++ drivers/char/hw_random/Makefile | 1 +

[PATCH v3 3/3] ARM: dts: exynos: Add nodes for True Random Number Generator

Add nodes for the True Random Number Generator found in Samsung Exynos 5250+ SoCs. Signed-off-by: Łukasz Stelmach --- arch/arm/boot/dts/exynos5.dtsi| 5 + arch/arm/boot/dts/exynos5250.dtsi | 5 + arch/arm/boot/dts/exynos5410.dtsi | 5 +