On Sat, Apr 25, 2020 at 10:24:14PM +0800, Tang Bin wrote:
> Delete unused initialized value in cipher.c file.
>
> Signed-off-by: Zhang Shengju
> Signed-off-by: Tang Bin
> ---
> drivers/crypto/bcm/cipher.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
Patch applied.
On Sat, Apr 25, 2020 at 10:22:58PM +0800, Tang Bin wrote:
> It's not necessary to specify 'int' casting for PTR_ERR().
>
> Signed-off-by: Zhang Shengju
> Signed-off-by: Tang Bin
> ---
> drivers/crypto/bcm/cipher.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Patch applied. Thanks.
Zou Wei wrote:
> Fix the following sparse warnings:
>
> drivers/char/hw_random/cctrng.c:316:6: warning: symbol
> 'cc_trng_compwork_handler' was not declared. Should it be static?
> drivers/char/hw_random/cctrng.c:451:6: warning: symbol
> 'cc_trng_startwork_handler' was not declared. Should it be
On Fri, Apr 24, 2020 at 01:40:44PM +, Corentin Labbe wrote:
> Hello
>
> Fix serie try to fix some DRBG depencies in Kconfig
>
> Change since v2:
> - added patch #2
>
> Changes since v1:
> - Updated commit message with recursive dependency
>
> Corentin Labbe (3):
> crypto: drbg: DRBG shoul
On Thu, Apr 23, 2020 at 10:22:36AM +0800, Zou Wei wrote:
> Fix the following sparse warning:
>
> drivers/crypto/hisilicon/qm.c:3079:5: warning: symbol 'qm_controller_reset'
> was not declared. Should it be static?
>
> Reported-by: Hulk Robot
> Signed-off-by: Zou Wei
> ---
> drivers/crypto/hisi
On Wed, Apr 22, 2020 at 05:18:53PM -0600, Jason A. Donenfeld wrote:
> The initial Zinc patchset, after some mailing list discussion, contained
> code to ensure that kernel_fpu_enable would not be kept on for more than
> a 4k chunk, since it disables preemption. The choice of 4k isn't totally
> scie
On Tue, Apr 21, 2020 at 02:47:04PM -0700, Nathan Chancellor wrote:
> When building 64r6_defconfig with CONFIG_MIPS32_O32 disabled and
> CONFIG_CRYPTO_RSA enabled:
>
> lib/mpi/generic_mpih-mul1.c:37:24: error: invalid use of a cast in a
> inline asm context requiring an l-value: remove the cast
> o
On Tue, Apr 21, 2020 at 12:44:49PM -0500, Tom Lendacky wrote:
> To provide support for SEV-ES, the hypervisor must provide an area of
> memory to the PSP. Once this Trusted Memory Region (TMR) is provided to
> the PSP, the contents of this area of memory are no longer available to
> the x86.
>
> U
On Wed, Apr 22, 2020 at 03:58:08PM +0300, Andy Shevchenko wrote:
> There is export_uuid() function which exports uuid_t to the u8 array.
> Use it instead of open coding variant.
>
> This allows to hide the uuid_t internals.
>
> Signed-off-by: Andy Shevchenko
> ---
> drivers/char/hw_random/optee
On Tue, Apr 21, 2020 at 12:34:55PM -0400, Daniel Jordan wrote:
> Removing the pcrypt module triggers this:
>
> general protection fault, probably for non-canonical
> address 0xdead0122
> CPU: 5 PID: 264 Comm: modprobe Not tainted 5.6.0+ #2
> Hardware name: QEMU Standard PC
> RI
users may call crypto_has_acomp to confirm the existence of acomp before using
crypto_acomp APIs. Right now, many acomp have scomp backend, for example, lz4,
lzo, deflate etc. crypto_has_acomp will return false for them even though they
support acomp APIs.
Signed-off-by: Barry Song
---
-v2: fixe
On Fri, Apr 24, 2020 at 01:40:45PM +, Corentin Labbe wrote:
> Since DRBG could use SHA384/SHA512, it should select it.
>
> Signed-off-by: Corentin Labbe
> ---
> crypto/Kconfig | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/crypto/Kconfig b/crypto/Kconfig
> index c24a47406f8f..6d
On Thu, Apr 30, 2020 at 12:47:32PM +1200, Barry Song wrote:
>
> diff --git a/include/crypto/acompress.h b/include/crypto/acompress.h
> index d873f999b334..a7170848e6c2 100644
> --- a/include/crypto/acompress.h
> +++ b/include/crypto/acompress.h
> @@ -156,7 +156,7 @@ static inline void crypto_free_a
users may call crypto_has_acomp to confirm the existence of acomp before using
crypto_acomp APIs. Right now, many of acomp have scomp backend, for example,
lz4, lzo, deflate etc. crypto_has_acomp will return false for them even though
they support acomp APIs.
One possible way to make has_acomp tru
The pull request you sent on Wed, 29 Apr 2020 15:54:20 +1000:
> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/6c3efdc911b67816285719bd610152232cf5e8e4
Thank you!
--
Deet-doot-dot, I am a bot
Most of the OMAP family SoCs contain two instances for AES core, which
causes the remove callbacks to be also done twice when driver is
removed. Fix the algorithm unregister callbacks to take into account the
number of algorithms still registered to avoid removing these twice.
Signed-off-by: Tero
With very small data sizes, the whole data can end up in the xmit
buffer. This code path does not set the sg_len properly which causes the
core dma framework to crash. Fix by adding the proper size in place.
Also, the data length must be a multiple of block-size, so extend the
DMA data size while h
The ctx internal buffer can only hold buflen amount of data, don't try
to copy over more than that. Also, initialize the context sg pointer
if we only have data in the context internal buffer, this can happen
when closing a hash with certain data amounts.
Signed-off-by: Tero Kristo
---
drivers/c
Hi,
A few fixes here for omap crypto drivers. These patches address issues
with openssl 1.1 support, and cases where someone actually does set the
fallback size for SHA driver to zero (enforcing HW accelerator usage for
everything)... There is also a recent change to crypto care that
surfaced the
In case buffers are copied from userspace, directly accessing the page
will most likely fail because it hasn't been mapped into the kernel
memory space. Fix the issue by forcing a kmap / kunmap within the
cleanup functionality.
Signed-off-by: Tero Kristo
---
drivers/crypto/omap-crypto.c | 7
As the hardware acceleration for the omap-sham algos is not available
from userspace, force kernel driver usage. Without this flag in place,
openssl 1.1 implementation thinks it can accelerate sha algorithms on
omap devices directly from userspace.
Signed-off-by: Tero Kristo
---
drivers/crypto/o
Running the self test suite for omap-aes with extra tests enabled causes
huge spam with the tag message wrong indicators. With self tests, this
is fine as there are some tests that purposedly pass bad data to the
driver. Also, returning -EBADMSG from the driver is enough, so remove the
dev_err mess
On Tue, Apr 21, 2020 at 12:44:49PM -0500, Tom Lendacky wrote:
> To provide support for SEV-ES, the hypervisor must provide an area of
> memory to the PSP. Once this Trusted Memory Region (TMR) is provided to
> the PSP, the contents of this area of memory are no longer available to
> the x86.
>
> U
23 matches
Mail list logo
