Hi all,
Today's linux-next merge of the sound-asoc tree got a conflict in:
sound/soc/codecs/cros_ec_codec.c
between commit:
85fc78b80f15 ("ASoC: cros_ec_codec: use crypto_shash_tfm_digest()")
from the crypto tree and commit:
a1304cba816e ("ASoC: cros_ec_codec: allocate shash_desc dynami
On 12/05/2020 00:53, Rob Herring wrote:
On Fri, Apr 24, 2020 at 07:44:24PM +0300, Tero Kristo wrote:
From: Keerthy
The Security Accelerator Ultra Lite (SA2UL) subsystem provides hardware
cryptographic acceleration for the following use cases:
* Encryption and authentication for secure boot
*
Some platform devices appear as PCI but are
actually on the AMBA bus, and they need fixup in
drivers/pci/quirks.c handling iommu_fwnode.
So calling pci_fixup_final after iommu_fwnode is allocated.
For example:
Hisilicon platform device need fixup in
drivers/pci/quirks.c
+static void quirk_huawe
Calling pci_fixup_final after iommu_fwspec_init, which alloc
iommu_fwnode. Some platform devices appear as PCI but are
actually on the AMBA bus, and they need fixup in
drivers/pci/quirks.c handling iommu_fwnode.
So calling pci_fixup_final after iommu_fwnode is allocated.
Signed-off-by: Zhangfei Ga
Calling pci_fixup_final after of_pci_iommu_init, which alloc
iommu_fwnode. Some platform devices appear as PCI but are
actually on the AMBA bus, and they need fixup in
drivers/pci/quirks.c handling iommu_fwnode.
So calling pci_fixup_final after iommu_fwnode is allocated.
Signed-off-by: Zhangfei Ga
Hi,
Sorry for disturbing you.
I got a question: which API should my I/O Crypto device driver use,
SHASH or AHASH?
For performance, I would like to use AHASH since I/O device doing better
at asynchronous mode.
Thanks,
Zaibo
.
On Fri, Apr 24, 2020 at 07:44:24PM +0300, Tero Kristo wrote:
> From: Keerthy
>
> The Security Accelerator Ultra Lite (SA2UL) subsystem provides hardware
> cryptographic acceleration for the following use cases:
>
> * Encryption and authentication for secure boot
> * Encryption and authentication
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
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
Hi,
Compared to v1 [1], added dcache flush handling in patch #3, and added a
new patch #7 which fixes SHA multi-accelerator core support. It doubles
the performance of raw SHA acceleration on devices where two cores are
available (like DRA7.) Will follow with platform code fixes once the
driver ch
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
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
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
The current implementation of the multiple accelerator core support for
OMAP SHA does not work properly. It always picks up the first probed
accelerator core if this is available, and rest of the book keeping also
gets confused if there are two cores available. Add proper load
balancing support for
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 | 9
15 matches
Mail list logo
