On 2020/5/31 17:21, Michael S. Tsirkin wrote:
> On Tue, May 26, 2020 at 02:11:37PM +, Sasha Levin wrote:
>> <20200123101000.GB24255@Red>
>> References: <20200526031956.1897-3-longpe...@huawei.com>
>> <20200123101000.GB24255@Red>
>>
>> Hi
>>
>> [This is an automated email]
>>
>> This commit h
Add a small bit of plumbing necessary to use CAAM on VFxxx SoCs.
Signed-off-by: Andrey Smirnov
Cc: Chris Healy
Cc: Horia Geantă
Cc: Herbert Xu
Cc: Fabio Estevam
Cc: linux-...@nxp.com
Cc: linux-crypto@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
---
drivers/crypto/caam/ctrl.c | 10 +++
Silex insight BA431 is an IP designed to generate random numbers that
can be integrated in various FPGA.
This driver adds support for it through the hwrng interface.
This driver is used in Silex Insight Viper OEM boards.
Signed-off-by: Olivier Sobrie
Signed-off-by: Waleed Ziad
Acked-by: Arnd Be
Hello all,
This set of patches aims at introducing a linux hwrng driver for the
Silex Insight BA431 IP which is available for various FPGA.
This hardware is for instance present in Silex Insight Viper OEM boards.
The first patch documents the device tree bindings.
The second one contains the BA43
This patch documents the device tree bindings of the BA431 hardware
random number generator.
This IP is for instance present in the Viper OEM boards sold by Silex
Insight.
Signed-off-by: Olivier Sobrie
Reviewed-by: Rob Herring
---
.../bindings/rng/silex-insight,ba431-rng.yaml | 36
The pull request you sent on Mon, 1 Jun 2020 12:45:33 +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/81e8c10dac62c427b25f6bbb07936806e4dd9e8a
Thank you!
--
Deet-doot-dot, I am a bot.
On Thu, May 28, 2020 at 09:33:44AM +0200, Joerg Roedel wrote:
> On Wed, May 27, 2020 at 01:18:42PM -0500, Bjorn Helgaas wrote:
> > Is this slowdown significant? We already iterate over every device
> > when applying PCI_FIXUP_FINAL quirks, so if we used the existing
> > PCI_FIXUP_FINAL, we wouldn'
Use GFP_KERNEL when the flag CRYPTO_TFM_REQ_MAY_SLEEP is present.
Also, use GFP_KERNEL when setting a key.
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernel.org
Index: linux-2.6/drivers/crypto/qat/qat_common/qat_algs.c
===
--- l
Using dm-crypt with QAT result in deadlocks.
If a crypto routine returns -EBUSY, it is expected that the crypto driver
have already queued the request and the crypto API user should assume that
this request was processed, but it should stop sending more requests. When
an -EBUSY request is processe
Hi
These patches fix bugs in the Intel QAT driver.
https://bugzilla.redhat.com/show_bug.cgi?id=1813394
Mikulas
Some hardware crypto drivers use GFP_ATOMIC allocations in the request
routine. These allocations can randomly fail - for example, they fail if
too many network packets are received.
If we propagated the failure up to the I/O stack, it would cause I/O
errors and data corruption. So, we sleep and r
This patch fixes a bug in QAT in async asymetric algorithm.
adf_send_message returns -EAGAIN when the queue is full. The caller
misunderstands it as -EBUSY - so the retry loop will never happen.
Furthermore, when the crypto driver return -EBUSY, it is expected that it
has queued the request and t
> From: kbuild test robot [mailto:l...@intel.com]
> security/integrity/ima/ima_crypto.c:575:12: warning: stack frame size of
> 1152 bytes in function 'ima_calc_field_array_hash_tfm'
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> master
> head: b0523c7b1c9d0edcd
On Thu, May 28, 2020 at 07:00:51PM +0200, sbuisson@gmail.com wrote:
> From: Sebastien Buisson
>
> Add adler32 to CryptoAPI so that it can be used with the normal kernel
> API, and potentially accelerated if architecture-specific
> optimizations are available.
>
> Signed-off-by: Sebastien Bui
14 matches
Mail list logo
