On 28/05/2020 19:54, Tero Kristo wrote:
On 28/05/2020 18:27, Rob Herring wrote:
On Thu, 14 May 2020 16:19:47 +0300, Tero Kristo wrote:
Convert TI OMAP Random number generator bindings to DT schema.
Signed-off-by: Tero Kristo
---
.../devicetree/bindings/rng/omap_rng.txt | 38
rypto: omap-sham - Add OMAP4/AM33XX SHAM Support")
Signed-off-by: Tero Kristo
---
drivers/crypto/omap-sham.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index b2b930a1fb04..a3b38d2c92e7 100644
--- a/drivers/crypto/omap-sham.c
+++
Convert the omap-sham driver to use crypto engine for queue handling,
instead of using local implementation.
Signed-off-by: Tero Kristo
---
drivers/crypto/omap-sham.c | 186 -
1 file changed, 78 insertions(+), 108 deletions(-)
diff --git a/drivers/crypto
Hi,
Here are couple of fixes for sa2ul driver. Found via static checkers.
-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
sizes for the example to 1 cell from
current 2.
Fixes: 2ce9a7299bf6 ("dt-bindings: crypto: Add TI SA2UL crypto accelerator
documentation")
Reported-by: Rob Herring
Cc: Rob Herring
Cc: devicet...@vger.kernel.org
Signed-off-by: Tero Kristo
---
Documentation/devicetree/bindings
Clang detects a warning for an assignment that doesn't really do
anything. Fix this by removing the offending piece of code.
Fixes: 7694b6ca649f ("crypto: sa2ul - Add crypto driver")
Reported-by: Nathan Chancellor
Signed-off-by: Tero Kristo
---
drivers/crypto/sa2ul.c | 6 ++
On 22/08/2020 01:17, Nathan Chancellor wrote:
On Mon, Jul 13, 2020 at 11:34:22AM +0300, Tero Kristo wrote:
From: Keerthy
Adds a basic crypto driver and currently supports AES/3DES
in cbc mode for both encryption and decryption.
Signed-off-by: Keerthy
[t-kri...@ti.com: major re-work to fix
On 23/07/2020 10:43, Herbert Xu wrote:
This patch fixes a bunch of initialiser warnings.
Signed-off-by: Herbert Xu
Looks ok to me, however I never saw any build warnings with the code
myself. Which compiler/version produces them?
-Tero
diff --git a/drivers/crypto/sa2ul.c b/drivers/crypt
On 09/07/2020 11:06, Herbert Xu wrote:
On Thu, Jul 09, 2020 at 06:03:01PM +1000, Herbert Xu wrote:
On Wed, Jul 01, 2020 at 11:05:48AM +0300, Tero Kristo wrote:
From: Keerthy
Adds a basic crypto driver and currently supports AES/3DES
in cbc mode for both encryption and decryption.
Signed-off
The child devices for sa2ul (like the RNG) have hard dependency towards
the parent, they can't function without the parent enabled. Add device
link for this purpose so that the dependencies are taken care of properly.
Signed-off-by: Tero Kristo
---
drivers/crypto/sa2ul.c | 11 +
From: Keerthy
Add crypto accelarator node for supporting hardware crypto algorithms,
including SHA1, SHA256, SHA512, AES, 3DES, and AEAD suites.
Signed-off-by: Keerthy
[t-kri...@ti.com: Modifications based on introduction of yaml binding]
Signed-off-by: Tero Kristo
---
arch/arm64/boot/dts/ti
From: Keerthy
Add support for sa2ul hardware AEAD for hmac(sha256),cbc(aes) and
hmac(sha1),cbc(aes) algorithms.
Signed-off-by: Keerthy
[t-kri...@ti.com: number of bug fixes, major refactoring and cleanup of
code]
Signed-off-by: Tero Kristo
---
drivers/crypto/sa2ul.c | 538
From: Keerthy
Add crypto accelarator node for supporting hardware crypto algorithms,
including SHA1, SHA256, SHA512, AES, 3DES, and AEAD suites.
Signed-off-by: Keerthy
[t-kri...@ti.com: Modifications based on introduction of yaml binding]
Signed-off-by: Tero Kristo
---
arch/arm64/boot/dts/ti
From: Keerthy
Adds a basic crypto driver and currently supports AES/3DES
in cbc mode for both encryption and decryption.
Signed-off-by: Keerthy
[t-kri...@ti.com: major re-work to fix various bugs in the driver and to
cleanup the code]
Signed-off-by: Tero Kristo
---
drivers/crypto/Kconfig
Hi,
V6 has only a bunch of static checker warnings fixed. Tested building
with W=1 and C=1 make options, also did a sanity test with crypto
manager tests + extra tests, and did a quick trial with tcrypt.
-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business
for a data chunk of known size.
Signed-off-by: Keerthy
[t-kri...@ti.com: various bug fixes, major cleanups and refactoring of code]
Signed-off-by: Tero Kristo
---
drivers/crypto/sa2ul.c | 549 -
drivers/crypto/sa2ul.h | 24 +-
2 files changed, 560
]
Signed-off-by: Tero Kristo
---
.../devicetree/bindings/crypto/ti,sa2ul.yaml | 76 +++
1 file changed, 76 insertions(+)
create mode 100644 Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml
diff --git a/Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml
b/Documentation
for a data chunk of known size.
Signed-off-by: Keerthy
[t-kri...@ti.com: various bug fixes, major cleanups and refactoring of code]
Signed-off-by: Tero Kristo
---
v5:
* converted sha_init/update/final sequence to use SW fallback only.
drivers/crypto/sa2ul.c | 547
From: Keerthy
Adds a basic crypto driver and currently supports AES/3DES
in cbc mode for both encryption and decryption.
Signed-off-by: Keerthy
[t-kri...@ti.com: major re-work to fix various bugs in the driver and to
cleanup the code]
Signed-off-by: Tero Kristo
---
drivers/crypto/Kconfig
]
Signed-off-by: Tero Kristo
---
.../devicetree/bindings/crypto/ti,sa2ul.yaml | 76 +++
1 file changed, 76 insertions(+)
create mode 100644 Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml
diff --git a/Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml
b/Documentation
Hi,
This latest incarnation of the series has patch #3 re-written for the
hash init/update/final sequencing only. As the HW accelerator can't
properly handle split up hashes, nor can its state be exported out, we
use software fallback now for all cases of hashing, except for digest.
Applies on to
The child devices for sa2ul (like the RNG) have hard dependency towards
the parent, they can't function without the parent enabled. Add device
link for this purpose so that the dependencies are taken care of properly.
Signed-off-by: Tero Kristo
---
drivers/crypto/sa2ul.c | 11 +
From: Keerthy
Add crypto accelarator node for supporting hardware crypto algorithms,
including SHA1, SHA256, SHA512, AES, 3DES, and AEAD suites.
Signed-off-by: Keerthy
[t-kri...@ti.com: Modifications based on introduction of yaml binding]
Signed-off-by: Tero Kristo
---
arch/arm64/boot/dts/ti
From: Keerthy
Add crypto accelarator node for supporting hardware crypto algorithms,
including SHA1, SHA256, SHA512, AES, 3DES, and AEAD suites.
Signed-off-by: Keerthy
[t-kri...@ti.com: Modifications based on introduction of yaml binding]
Signed-off-by: Tero Kristo
---
arch/arm64/boot/dts/ti
From: Keerthy
Add support for sa2ul hardware AEAD for hmac(sha256),cbc(aes) and
hmac(sha1),cbc(aes) algorithms.
Signed-off-by: Keerthy
[t-kri...@ti.com: number of bug fixes, major refactoring and cleanup of
code]
Signed-off-by: Tero Kristo
---
drivers/crypto/sa2ul.c | 538
On 30/06/2020 10:59, Herbert Xu wrote:
On Tue, Jun 30, 2020 at 10:58:28AM +0300, Tero Kristo wrote:
Openssl uses init->update->final sequencing, and it would be nice to have
this use crypto accelerator. Otherwise we basically support cipher
acceleration from openssl, but not hashing.
On 30/06/2020 10:54, Herbert Xu wrote:
On Tue, Jun 30, 2020 at 10:52:57AM +0300, Tero Kristo wrote:
How about making the buffer size configurable during probe time via module
param, and/or runtime via sysfs parameter? This would allow system designers
to tune it based on expected usecases
On 30/06/2020 10:46, Herbert Xu wrote:
On Tue, Jun 30, 2020 at 10:20:06AM +0300, Tero Kristo wrote:
Only up-to block size? This would limit the buffer to 64-128 bytes.
The exported hash state is not supposed to be used to support
hardware that does not support partial hashing.
These states
On 30/06/2020 07:49, Herbert Xu wrote:
On Fri, Jun 26, 2020 at 12:15:42PM +0300, Tero Kristo wrote:
I have been experimenting with an alternate approach, where I have a small
buffer within the context, this would be more like the way other drivers do
this. If the buffer is closed before
On 26/06/2020 07:31, Herbert Xu wrote:
On Mon, Jun 15, 2020 at 10:14:48AM +0300, Tero Kristo wrote:
+static int sa_sha_update(struct ahash_request *req)
+{
+ struct sa_sha_req_ctx *rctx = ahash_request_ctx(req);
+ struct scatterlist *sg;
+ void *buf;
+ int pages
On 18/06/2020 10:28, Herbert Xu wrote:
On Fri, Jun 12, 2020 at 11:22:02PM +0200, Julia Lawall wrote:
From: kernel test robot
PTR_ERR should normally access the value just tested by IS_ERR
Generated by: scripts/coccinelle/tests/odd_ptr_err.cocci
Fixes: 5b8516f3bedb ("crypto: sa2ul: Add crypto
On 15/06/2020 14:36, Herbert Xu wrote:
This patch fixes sparse endianness warnings as well as compiler
warnings on 64-bit hosts.
Signed-off-by: Herbert Xu
Looks fine to me:
Reviewed-by: Tero Kristo
diff --git a/drivers/crypto/omap-des.c b/drivers/crypto/omap-des.c
index 8eda43319204
On 15/06/2020 14:37, Herbert Xu wrote:
This patch fixes sparse endianness warnings as well as compiler
warnings on 64-bit hosts.
Signed-off-by: Herbert Xu
Looks okay to me.
Reviewed-by: Tero Kristo
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index 82691a057d2a
On 15/06/2020 21:20, Eric Biggers wrote:
On Mon, Jun 15, 2020 at 10:14:45AM +0300, Tero Kristo wrote:
Hi,
This is basically just a rebase of v2 to 5.8-rc1, and application of
Rob's Ack on the dt-binding patch. No other changes.
Only driver side + DT binding should be applied via the c
]
Signed-off-by: Tero Kristo
---
.../devicetree/bindings/crypto/ti,sa2ul.yaml | 76 +++
1 file changed, 76 insertions(+)
create mode 100644 Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml
diff --git a/Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml
b/Documentation
Hi,
This is basically just a rebase of v2 to 5.8-rc1, and application of
Rob's Ack on the dt-binding patch. No other changes.
Only driver side + DT binding should be applied via the crypto tree, DTS
patches should be queued separately via ARM SoC tree (I can take care of
that myself assuming the
From: Keerthy
Add support for sha1/sha256/sha512 sa2ul based hardware authentication.
Signed-off-by: Keerthy
[t-kri...@ti.com: various bug fixes, major cleanups and refactoring of code]
Signed-off-by: Tero Kristo
---
drivers/crypto/sa2ul.c | 582
From: Keerthy
Adds a basic crypto driver and currently supports AES/3DES
in cbc mode for both encryption and decryption.
Signed-off-by: Keerthy
[t-kri...@ti.com: major re-work to fix various bugs in the driver and to
cleanup the code]
Signed-off-by: Tero Kristo
---
drivers/crypto/Kconfig
From: Keerthy
Add crypto accelarator node for supporting hardware crypto algorithms,
including SHA1, SHA256, SHA512, AES, 3DES, and AEAD suites.
Signed-off-by: Keerthy
[t-kri...@ti.com: Modifications based on introduction of yaml binding]
Signed-off-by: Tero Kristo
---
arch/arm64/boot/dts/ti
From: Keerthy
Add support for sa2ul hardware AEAD for hmac(sha256),cbc(aes) and
hmac(sha1),cbc(aes) algorithms.
Signed-off-by: Keerthy
[t-kri...@ti.com: number of bug fixes, major refactoring and cleanup of
code]
Signed-off-by: Tero Kristo
---
drivers/crypto/sa2ul.c | 538
The child devices for sa2ul (like the RNG) have hard dependency towards
the parent, they can't function without the parent enabled. Add device
link for this purpose so that the dependencies are taken care of properly.
Signed-off-by: Tero Kristo
---
drivers/crypto/sa2ul.c | 11 +
From: Keerthy
Add crypto accelarator node for supporting hardware crypto algorithms,
including SHA1, SHA256, SHA512, AES, 3DES, and AEAD suites.
Signed-off-by: Keerthy
[t-kri...@ti.com: Modifications based on introduction of yaml binding]
Signed-off-by: Tero Kristo
---
arch/arm64/boot/dts/ti
On 03/06/2020 15:39, Herbert Xu wrote:
On Wed, Jun 03, 2020 at 03:38:03PM +0300, Tero Kristo wrote:
Also I guess this should be posted against 5.8-rc1 once it is out, as merge
window is already open. Or are you planning to pick it up for 5.8 already?
Sorry this is going to be in the next
On 03/06/2020 15:27, Herbert Xu wrote:
On Wed, Jun 03, 2020 at 01:01:26PM +0300, Tero Kristo wrote:
Herbert, whats the plan with the rest of the series? Do you want me to
re-post it? It shows deferred under crypto patchwork currently.
Please repost because v3 contains just a single patch
On 28/05/2020 18:23, Rob Herring wrote:
On Thu, 14 May 2020 15:50:05 +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
On 28/05/2020 18:27, Rob Herring wrote:
On Thu, 14 May 2020 16:19:47 +0300, Tero Kristo wrote:
Convert TI OMAP Random number generator bindings to DT schema.
Signed-off-by: Tero Kristo
---
.../devicetree/bindings/rng/omap_rng.txt | 38 -
.../devicetree/bindings/rng/ti,omap
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
message completely.
Signed-off-by: Tero Kristo
---
drivers/crypto/omap-aes-gcm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/crypto/omap-aes-gcm.c b/drivers/crypto/omap-aes-gcm.c
index 32dc00dc570b..9f937bdc53a7 100644
--- a/drivers/crypto/omap-aes-gcm.c
+++ b/drivers/crypto/omap-aes
here.
Signed-off-by: Tero Kristo
---
drivers/crypto/omap-sham.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index 9823d7dfca9c..86949f1ac6a7 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -753,9 +753,11
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
---
v3:
- Added PageSlab() check t
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
---
dr
Hi,
Resent the whole series as-per request. Only patch changed compared to
v2 [1] is patch #3. Cache flushing logic has been fixed on it based on
comments.
-Tero
[1] https://patchwork.kernel.org/cover/11540265/
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Busin
for SHA, and also fix any bugs related to the
multicore support while doing it.
Signed-off-by: Tero Kristo
---
drivers/crypto/omap-sham.c | 64 ++
1 file changed, 31 insertions(+), 33 deletions(-)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap
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
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
---
v3:
- Added PageSlab() check t
On 14/05/2020 15:50, 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 of content in applications
On 26/05/2020 16:07, Herbert Xu wrote:
On Tue, May 26, 2020 at 03:57:10PM +0300, Tero Kristo wrote:
Btw, any word on the TI sa2ul series I posted a while back? I see it has
been marked as deferred in patchwork but I am not quite sure what that
means... deferred until what? I have also been
On 26/05/2020 15:35, Herbert Xu wrote:
On Tue, May 26, 2020 at 03:27:38PM +0300, Tero Kristo wrote:
I think it would make sense to use that, however as I am just fixing an
existing bug here, would it be ok if I just fix your above comment and post
v3? I can convert this later to sg_miter and
On 22/05/2020 16:12, Herbert Xu wrote:
On Mon, May 11, 2020 at 02:19:09PM +0300, Tero Kristo wrote:
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 / k
Convert TI OMAP Random number generator bindings to DT schema.
Signed-off-by: Tero Kristo
---
.../devicetree/bindings/rng/omap_rng.txt | 38 -
.../devicetree/bindings/rng/ti,omap-rng.yaml | 77 +++
2 files changed, 77 insertions(+), 38 deletions(-)
delete mode
documentation to yaml]
Signed-off-by: Tero Kristo
---
v3:
- fixed a typo in rng child node regex
.../devicetree/bindings/crypto/ti,sa2ul.yaml | 76 +++
1 file changed, 76 insertions(+)
create mode 100644 Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml
diff --git a
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
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
here.
Signed-off-by: Tero Kristo
---
drivers/crypto/omap-sham.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index 9823d7dfca9c..86949f1ac6a7 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -753,9 +753,11
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
---
dr
message completely.
Signed-off-by: Tero Kristo
---
drivers/crypto/omap-aes-gcm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/crypto/omap-aes-gcm.c b/drivers/crypto/omap-aes-gcm.c
index 32dc00dc570b..9f937bdc53a7 100644
--- a/drivers/crypto/omap-aes-gcm.c
+++ b/drivers/crypto/omap-aes
for SHA, and also fix any bugs related to the
multicore support while doing it.
Signed-off-by: Tero Kristo
---
drivers/crypto/omap-sham.c | 64 ++
1 file changed, 31 insertions(+), 33 deletions(-)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap
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.
On 08/05/2020 08:08, Herbert Xu wrote:
On Wed, Apr 29, 2020 at 05:42:02PM +0300, Tero Kristo wrote:
diff --git a/drivers/crypto/omap-crypto.c b/drivers/crypto/omap-crypto.c
index cc88b7362bc2..cbc5a4151c3c 100644
--- a/drivers/crypto/omap-crypto.c
+++ b/drivers/crypto/omap-crypto.c
@@ -178,11
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
here.
Signed-off-by: Tero Kristo
---
drivers/crypto/omap-sham.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index 9823d7dfca9c..86949f1ac6a7 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -753,9 +753,11
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
---
dr
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.
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
message completely.
Signed-off-by: Tero Kristo
---
drivers/crypto/omap-aes-gcm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/crypto/omap-aes-gcm.c b/drivers/crypto/omap-aes-gcm.c
index 32dc00dc570b..9f937bdc53a7 100644
--- a/drivers/crypto/omap-aes-gcm.c
+++ b/drivers/crypto/omap-aes
Aligned data cleanup is using wrong pointers in the cleanup calls. Most
of the time these are right, but can cause mysterious problems in some
cases. Fix to use the same pointers that were used with the align call.
Signed-off-by: Tero Kristo
---
drivers/crypto/omap-aes.c | 4 ++--
1 file
warning print if a timeout happens.
Signed-off-by: Tero Kristo
---
include/linux/crypto.h | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/include/linux/crypto.h b/include/linux/crypto.h
index 19ea3a371d7b..b8f0e5c3cc0c 100644
--- a/include/linux/crypto.h
+++ b/include/linux
instead to smaller requests so that the kernel
can allocate the data, and also so that the DMA driver can handle
the separate SG elements.
Signed-off-by: Tero Kristo
Tested-by: Bin Liu
---
drivers/crypto/omap-sham.c | 81 ++
1 file changed, 64 insertions(+), 17
some cleanup
for the code at the same time to cut away some unnecessary code so that
it is easier to fix.
Signed-off-by: Tero Kristo
---
drivers/crypto/omap-sham.c | 102 -
1 file changed, 33 insertions(+), 69 deletions(-)
diff --git a/drivers/crypto/omap
Hi,
This series fixes a number of bugs with omap crypto implementation.
These have become evident with the changes to the cryptomanager, where
it adds some new test cases and modifies some existing, namely the split
update tests. Also, while fixing the cryptomanager induced bugs, some
other surfac
The driver removal should also cleanup the created sysfs group. If not,
the driver fails the subsequent probe as the files exist already.
Signed-off-by: Tero Kristo
---
drivers/crypto/omap-sham.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto
(the last request never completes fully due
to missing data.)
Fix this by passing the total size of the data instead of the data size
of current request, and also parsing the buffer contents within the
prepare request handling.
Signed-off-by: Tero Kristo
---
drivers/crypto/omap-sham.c | 15
The driver removal should also cleanup the created sysfs group. If not,
the driver fails the subsequent probe as the files exist already. Also,
drop a completely unnecessary pointer assignment from the removal
function at the same time.
Signed-off-by: Tero Kristo
---
drivers/crypto/omap-aes.c
Fix a corner case where only authdata is generated, without any provided
assocdata / cryptdata. Passing the empty scatterlists to OMAP AES core driver
in this case would confuse it, failing to map DMAs.
Signed-off-by: Tero Kristo
---
drivers/crypto/omap-aes-gcm.c | 22 ++
1
Currently omap-des driver does not copy end result IV out at all. This
is evident with the additional checks done at the crypto test manager.
Fix by copying out the IV values from HW.
Signed-off-by: Tero Kristo
---
drivers/crypto/omap-des.c | 6 ++
1 file changed, 6 insertions(+)
diff
Currently omap-aes driver does not copy end result IV out at all. This
is evident with the additional checks done at the crypto test manager.
Fix by copying out the IV values from HW.
Signed-off-by: Tero Kristo
---
drivers/crypto/omap-aes.c | 12
1 file changed, 12 insertions
On 17/10/2019 14:56, Ard Biesheuvel wrote:
On Thu, 17 Oct 2019 at 13:25, Tero Kristo wrote:
On 17/10/2019 13:45, Ard Biesheuvel wrote:
On Thu, 17 Oct 2019 at 12:25, Tero Kristo wrote:
On 15/10/2019 20:28, Tony Lindgren wrote:
* Ard Biesheuvel [191014 12:20]:
Commit 7a7ffe65c8c5
On 17/10/2019 13:45, Ard Biesheuvel wrote:
On Thu, 17 Oct 2019 at 12:25, Tero Kristo wrote:
On 15/10/2019 20:28, Tony Lindgren wrote:
* Ard Biesheuvel [191014 12:20]:
Commit 7a7ffe65c8c5 ("crypto: skcipher - Add top-level skcipher interface")
dated 20 august 2015 introduc
On 15/10/2019 20:28, Tony Lindgren wrote:
* Ard Biesheuvel [191014 12:20]:
Commit 7a7ffe65c8c5 ("crypto: skcipher - Add top-level skcipher interface")
dated 20 august 2015 introduced the new skcipher API which is supposed to
replace both blkcipher and ablkcipher. While all consumers of the API
he patches
changed. Please review again :)
Series looks fine to me also, don't have possibility to test omap3 ROM
RNG though (don't have HW for this.) For the whole series:
Reviewed-by: Tero Kristo
Regards,
Tony
Changes since v1:
- Use clk_prepare_enable() as pointed out by
Acked-by: Tero Kristo
---
drivers/crypto/omap-sham.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index 86b89ace836f..07235d0be29c 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -1082
Hi Francis,
This has similar checkpatch issues + being split into multipart message
as your other patch.
Also, I think this patch should be split up in two, as there are two
issues you are fixing; the bad pointer issue (which I think you only
fixed partially, also the in->sgl has similar pro
On 23/03/18 15:50, Tero Kristo wrote:
Hi Francis,
Your email program is still messing up things, the patch was sent as a
multipart message. Use git-send-email tool or something similar if
possible.
Also, there are at least two checkpatch issues (run
scripts/checkpatch.pl -strict ), in
Hi Francis,
Your email program is still messing up things, the patch was sent as a
multipart message. Use git-send-email tool or something similar if possible.
Also, there are at least two checkpatch issues (run
scripts/checkpatch.pl -strict ), in addition to the UTF-8
formatted message cont
e.
Remove the indentation to fix Smatch warning:
drivers/crypto/omap-sham.c:1761 omap_sham_done_task() warn: inconsistent
indenting
Signed-off-by: Krzysztof Kozlowski
Acked-by: Tero Kristo
---
drivers/crypto/omap-sham.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
di
re_request() warn: variable
dereferenced before check 'req' (see line 805)
Signed-off-by: Krzysztof Kozlowski
Acked-by: Tero Kristo
---
drivers/crypto/omap-sham.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.
is capable of DMA.
Signed-off-by: Tero Kristo
---
drivers/crypto/omap-crypto.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/crypto/omap-crypto.c b/drivers/crypto/omap-crypto.c
index 23e3777..2c42e4b 100644
--- a/drivers/crypto/omap-crypto.c
+++ b/drivers/crypto/omap-crypt
1 - 100 of 215 matches
Mail list logo
