Re: [PATCH] MAINTAINERS: Add Krzysztof Kozlowski as maintainer of crypto/s5p-sss

On Fri, Mar 10, 2017 at 11:18:13PM +0200, Vladimir Zapolskiy wrote: > Hi Krzysztof, > > On 03/10/2017 09:10 PM, Krzysztof Kozlowski wrote: > > Beside developing of this driver recently, I handle also reviews and > > bug reports from users so having a maintainer entry will ensure that I > > will

Re: [RFC PATCH v2 14/32] x86: mm: Provide support to use memblock when spliting large pages

Hi Boris, On 03/10/2017 05:06 AM, Borislav Petkov wrote: On Thu, Mar 02, 2017 at 10:15:15AM -0500, Brijesh Singh wrote: If kernel_maps_pages_in_pgd is called early in boot process to change the kernel_map_pages_in_pgd() memory attributes then it fails to allocate memory when spliting large

Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.

Sure, I went ahead and rebuilt it just using the bare exynos_defconfig and adding XTS and ECB and no other changes. No flags were used. No patches were used other than the 2 you provided. Just the barest of bears, the barest of bones, the barest of deserts, the barest of hairless cats. I also

Re: [PATCH] MAINTAINERS: Add Krzysztof Kozlowski as maintainer of crypto/s5p-sss

Hi Krzysztof, On 03/10/2017 09:10 PM, Krzysztof Kozlowski wrote: > Beside developing of this driver recently, I handle also reviews and > bug reports from users so having a maintainer entry will ensure that I > will be CC-ed on important emails. if you assume that the driver needs a special

[PATCH] MAINTAINERS: Add Krzysztof Kozlowski as maintainer of crypto/s5p-sss

Beside developing of this driver recently, I handle also reviews and bug reports from users so having a maintainer entry will ensure that I will be CC-ed on important emails. Cc: Vladimir Zapolskiy Cc: Herbert Xu Signed-off-by: Krzysztof Kozlowski

[PATCH] crypto: ccp - Assign DMA commands to the channel's CCP

From: Gary R Hook The CCP driver generally uses a round-robin approach when assigning operations to available CCPs. For the DMA engine, however, the DMA mappings of the SGs are associated with a specific CCP. When an IOMMU is enabled, the IOMMU is programmed based on this specific

Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.

On Thu, Mar 09, 2017 at 05:16:35AM -0600, Nathan Royce wrote: > Gave it a try on 4.10.1, but still to no avail: (...) > Also for the sake of testing, I did not add any FLAGS for compilation this > time. Damn, I am fixing bugs around but not the one you are hitting. Can you also check if

Re: [RFC PATCH v2 12/32] x86: Add early boot support when running with SEV active

Hi Boris and Paolo, On 03/09/2017 10:29 AM, Borislav Petkov wrote: On Thu, Mar 09, 2017 at 05:13:33PM +0100, Paolo Bonzini wrote: This is not how you check if running under a hypervisor; you should check the HYPERVISOR bit, i.e. bit 31 of cpuid(1).ecx. This in turn tells you if leaf

dm-crypt IV generation (summary)

Hi all, I was tasked to post a summary the whole dm-crypt IV generation problem and all the suggested solutions along with their drawbacks, so here it goes... PROBLEM STATEMENT: Currently, dm-crypt uses a fixed 512-byte sector size and handles en-/decrypting of a bio by submitting a separate

CRYPTO_MAX_ALG_NAME is too low

Hello crypto maintainers! We've found and example of the ipsec algorithm combination, which doesn't fit into CRYPTO_MAX_ALG_NAME long buffers: ip x s add src 1.1.1.1 dst 1.1.1.2 proto esp spi 0 mode tunnel enc des3_ede 0x0 auth sha256 0x0 flag esn replay-window 256 produces

Re: [RFC PATCH v2 14/32] x86: mm: Provide support to use memblock when spliting large pages

On Thu, Mar 02, 2017 at 10:15:15AM -0500, Brijesh Singh wrote: > If kernel_maps_pages_in_pgd is called early in boot process to change the kernel_map_pages_in_pgd() > memory attributes then it fails to allocate memory when spliting large > pages. The patch extends the cpa_data to provide the

[ANNOUNCE] /dev/random - a new approach (code for 4.11-rc1)

Hi, The patch set that can be downloaded at [1] provides a different approach to / dev/random which I call Linux Random Number Generator (LRNG) to collect entropy within the Linux kernel. The main improvements compared to the legacy /dev/random is to provide sufficient entropy during boot time