Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface

Am Mittwoch, 22. Juni 2016, 15:45:38 schrieb Mat Martineau: Hi Mat, > > > > Ok, I'll update the patch. > > Thanks, that helps (especially with pkcs1pad). Tadeusz received the updated patch from me to integrate it into his patch set. > > This brings me to another proposal for read buffer

Re: [PATCHv2 00/27] crypto: fixes for omap family of devices

* Tero Kristo [160622 06:27]: > Hi, > > Changes compared to v1 of the series: > > - dropped first patch from the series (crypto: omap-aes: Fix registration of > algorithms) as it was queued by Herbert already > - modified the second (now first) patch of the series to use

Re: Doing crypto in small stack buffers (bluetooth vs vmalloc-stack crash, etc)

On Wed, Jun 22, 2016 at 04:45:46PM -0700, Andy Lutomirski wrote: > > *However*, the other offender I've found (net/rxrpc/rxkad.c) uses > "pcbc(fcrypt)", which doesn't appear to be usable with this API. Is > there no way to say "I want synchronous crypto on this VA range" using > the skcipher API?

Re: Doing crypto in small stack buffers (bluetooth vs vmalloc-stack crash, etc)

On Wed, Jun 22, 2016 at 02:48:24PM -0700, Andy Lutomirski wrote: > > Before I do this, can you explain what the difference is between > crypto_cipher and crypto_skcipher? net/bluetooth/smp.c currently uses > crypto_alloc_skcipher, which you added in: crypto_cipher operates on a single block.

Re: [PATCH 4/8] crypto: rsa-pkcs1pad - Require hash to be present

On Wed, Jun 22, 2016 at 08:39:09AM -0700, Mat Martineau wrote: > > David Howells has a keyctl patch set in progress that makes use of > pkcs1pad, with or without a hash: > >

Re: [PATCH 0/3] hw_random: bcm2835: Add support for Broadcom BCM5301x

Patch series looks good. Acked-by: Scott Branden On 16-06-22 05:27 PM, Florian Fainelli wrote: Hi all, This patch series adds support for the Broadcom BCM5301x SoCs random number generator which is the same block as the one found in NSP and BCM2835. Florian

[PATCH 3/3] ARM: dts: BCM5301x: Add RNG Device Tree node

Add the DT node for the random number generator peripheral. Signed-off-by: Florian Fainelli --- arch/arm/boot/dts/bcm5301x.dtsi | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi index

[PATCH 1/3] Documentation: devicetree: bindings: Add BCM5301x binding

Document the binding used by the Broadcom BCM5301x (Northstar) SoC random number generator. Signed-off-by: Florian Fainelli --- Documentation/devicetree/bindings/rng/brcm,bcm2835.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

[PATCH 2/3] hw_random: bcm2835: Add support for Broadcom BCM5301x

The Broadcom BCM5301x SoCs (Northstar) utilize the same random number generator peripheral as Northstar Plus and BCM2835, but just like the NSP SoC, we need to enable the interrupt. Signed-off-by: Florian Fainelli --- drivers/char/hw_random/Kconfig | 2 +-

[PATCH 0/3] hw_random: bcm2835: Add support for Broadcom BCM5301x

Hi all, This patch series adds support for the Broadcom BCM5301x SoCs random number generator which is the same block as the one found in NSP and BCM2835. Florian Fainelli (3): Documentation: devicetree: bindings: Add BCM5301x binding hw_random: bcm2835: Add support for Broadcom BCM5301x

Re: Doing crypto in small stack buffers (bluetooth vs vmalloc-stack crash, etc)

On Wed, Jun 22, 2016 at 2:48 PM, Andy Lutomirski wrote: > On Tue, Jun 21, 2016 at 5:52 PM, Andy Lutomirski wrote: >> On Tue, Jun 21, 2016 at 5:42 PM, Herbert Xu >> wrote: >>> On Tue, Jun 21, 2016 at 10:43:40AM -0700, Andy

Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface

Stephan and Tadeusz, On Fri, 10 Jun 2016, Tadeusz Struk wrote: On 06/09/2016 11:36 AM, Stephan Mueller wrote: Am Donnerstag, 9. Juni 2016, 11:27:13 schrieb Mat Martineau: Hi Mat, Tadeusz, Ok, after checking the code again, I think that dropping that sanity check should be ok given that

Re: Doing crypto in small stack buffers (bluetooth vs vmalloc-stack crash, etc)

On Tue, Jun 21, 2016 at 5:52 PM, Andy Lutomirski wrote: > On Tue, Jun 21, 2016 at 5:42 PM, Herbert Xu > wrote: >> On Tue, Jun 21, 2016 at 10:43:40AM -0700, Andy Lutomirski wrote: >>> >>> Is there a straightforward way that bluetooth and,

Re: [Y2038] [PATCH v2] crypto: Jitter RNG - use ktime_get_ns as fallback

On Wednesday, June 22, 2016 7:26:06 PM CEST Stephan Mueller wrote: > As part of the Y2038 development, __getnstimeofday is not supposed to be > used any more. It is now replaced with ktime_get_ns. The Jitter RNG uses > the time stamp to measure the execution time of a given code path and > tries

Re: [PATCH] crypto: user - re-add size check for CRYPTO_MSG_GETALG

On 22 June 2016 at 21:03, Stephan Mueller wrote: > Am Mittwoch, 22. Juni 2016, 20:29:37 schrieb Mathias Krause: > > Hi Mathias, > >> Commit 9aa867e46565 ("crypto: user - Add CRYPTO_MSG_DELRNG") >> accidentally removed the minimum size check for CRYPTO_MSG_GETALG >> netlink

Re: [PATCH] crypto: user - re-add size check for CRYPTO_MSG_GETALG

Am Mittwoch, 22. Juni 2016, 20:29:37 schrieb Mathias Krause: Hi Mathias, > Commit 9aa867e46565 ("crypto: user - Add CRYPTO_MSG_DELRNG") > accidentally removed the minimum size check for CRYPTO_MSG_GETALG > netlink messages. This allows userland to send a truncated > CRYPTO_MSG_GETALG message as

[PATCH] crypto: user - re-add size check for CRYPTO_MSG_GETALG

Commit 9aa867e46565 ("crypto: user - Add CRYPTO_MSG_DELRNG") accidentally removed the minimum size check for CRYPTO_MSG_GETALG netlink messages. This allows userland to send a truncated CRYPTO_MSG_GETALG message as short as a netlink header only making crypto_report() operate on uninitialized

Re: [Y2038] [PATCH v2] crypto: Jitter RNG - use ktime_get_ns as fallback

On Wed, Jun 22, 2016 at 10:26 AM, Stephan Mueller wrote: > Hi John, Herbert, > > Changes v2: use ktime_get_ns instead of ktime_get_raw_ns > > The testing was re-performed and indicate no difference to the previous > testing. Thanks for following through on this. This

[PATCH v2] crypto: Jitter RNG - use ktime_get_ns as fallback

Hi John, Herbert, Changes v2: use ktime_get_ns instead of ktime_get_raw_ns The testing was re-performed and indicate no difference to the previous testing. Ciao Stephan ---8<--- As part of the Y2038 development, __getnstimeofday is not supposed to be used any more. It is now replaced with

[PATCH v11 0/3] Key-agreement Protocol Primitives (KPP) API

Hi Herb, the following patchset introduces a new API for abstracting key-agreement protocols such as DH and ECDH. It provides the primitives required for implementing the protocol, thus the name KPP (Key-agreement Protocol Primitives). Regards, Salvatore Changes from v10: * Remove all DH/ECDH

[PATCH v11 3/3] crypto: kpp - Add ECDH software support

* Implement ECDH under kpp API * Provide ECC software support for curve P-192 and P-256. * Add kpp test for ECDH with data generated by OpenSSL Signed-off-by: Salvatore Benedetto --- crypto/Kconfig |5 + crypto/Makefile |4 +

[PATCH v11 1/3] crypto: Key-agreement Protocol Primitives API (KPP)

Add key-agreement protocol primitives (kpp) API which allows to implement primitives required by protocols such as DH and ECDH. The API is composed mainly by the following functions * set_secret() - It allows the user to set his secret, also referred to as his private key, along with the

[PATCH v11 2/3] crypto: kpp - Add DH software implementation

* Implement MPI based Diffie-Hellman under kpp API * Test provided uses data generad by OpenSSL Signed-off-by: Salvatore Benedetto --- crypto/Kconfig | 8 ++ crypto/Makefile | 4 + crypto/dh.c | 189

Re: [PATCH 4/8] crypto: rsa-pkcs1pad - Require hash to be present

Herbert, On Wed, 22 Jun 2016, Herbert Xu wrote: On Wed, Jun 22, 2016 at 09:30:12AM -0500, Denis Kenzior wrote: We live on the bleeding edge :) I realize that these features are not upstream yet, but that doesn't mean that we can't influence / see the direction that the kernel is taking and

Re: [PATCH 4/8] crypto: rsa-pkcs1pad - Require hash to be present

Hi Herbert, On 06/22/2016 09:20 AM, Herbert Xu wrote: On Wed, Jun 22, 2016 at 09:19:16AM -0500, Denis Kenzior wrote: Just to clarify, we use this from userspace. So we _already_ depend on this functionality. Please keep the hash and non-hash versions of pkcs1pad available. How can you be

Re: [PATCH 4/8] crypto: rsa-pkcs1pad - Require hash to be present

On Wed, Jun 22, 2016 at 09:30:12AM -0500, Denis Kenzior wrote: > > We live on the bleeding edge :) > > I realize that these features are not upstream yet, but that doesn't > mean that we can't influence / see the direction that the kernel is > taking and act accordingly. > > We'd like to have

Re: KEYS: Use skcipher for big keys

Herbert Xu wrote: > I'm in the process of removing blkcipher/ablkcipher which have > been replaced with skcipher. It would be nice if we stop adding > new users of these two interfaces :) > > Anyway, if you guys are OK with this patch I'd like to push it > through

Re: [PATCH 4/8] crypto: rsa-pkcs1pad - Require hash to be present

On Wed, Jun 22, 2016 at 09:19:16AM -0500, Denis Kenzior wrote: > Just to clarify, we use this from userspace. So we _already_ depend > on this functionality. Please keep the hash and non-hash versions > of pkcs1pad available. How can you be depending on this in userspace when we haven't even

Re: [PATCH 4/8] crypto: rsa-pkcs1pad - Require hash to be present

Hi Herbert, On 06/22/2016 09:02 AM, Herbert Xu wrote: On Wed, Jun 22, 2016 at 03:20:51PM +0200, Andrzej Zaborowski wrote: We use pkcs1pad with AF_ALG to implement lightweight TLS. TLS versions < 1.2 use a non-standard hash so we'd have to move the PKCS#1 padding back to userspace if this is

KEYS: Use skcipher for big keys

Hi: I'm in the process of removing blkcipher/ablkcipher which have been replaced with skcipher. It would be nice if we stop adding new users of these two interfaces :) Anyway, if you guys are OK with this patch I'd like to push it through cryptodev so I can carry on with the removal of

[PATCHv2 27/27] ARM: AMx3xx: hwmod: Add data for RNG

From: Lokesh Vutla Hardware random number generator is present in both AM33xx and AM43xx SoC's. So moving the hwmod data to common data. Signed-off-by: Lokesh Vutla Signed-off-by: Tero Kristo ---

Re: [PATCH 4/8] crypto: rsa-pkcs1pad - Require hash to be present

Hi Herbert, On 22 June 2016 at 12:16, Herbert Xu wrote: > The only user of rsa-pkcs1pad always uses the hash so there is > no reason to support the case of not having a hash. We use pkcs1pad with AF_ALG to implement lightweight TLS. TLS versions < 1.2 use a

[PATCHv2 08/27] crypto: omap-des: Fix support for unequal lengths

From: Lokesh Vutla For cases where total length of an input SGs is not same as length of the input data for encryption, omap-des driver crashes. This happens in the case when IPsec is trying to use omap-des driver. To avoid this, we copy all the pages from the input SG list

[PATCHv2 14/27] crypto: omap-des: fix crypto engine initialization order

The crypto engine must be initialized before registering algorithms, otherwise the test manager will crash as it attempts to execute tests for the algos while they are being registered. Fixes: f1b77aaca85a ("crypto: omap-des - Integrate with the crypto engine framework") Signed-off-by: Tero

[PATCHv2 11/27] crypto: omap-aes: Add fallback support

From: Lokesh Vutla As setting up the DMA operations is quite costly, add software fallback support for requests smaller than 200 bytes. This change gives some 10% extra performance in ipsec use case. Signed-off-by: Lokesh Vutla Signed-off-by: Tero Kristo

[PATCHv2 12/27] crypto: engine: avoid unnecessary context switches

Crypto engine will now hi-jack the currently running thread for executing crypto functionality. Only if we are not running a thread (in interrupt context) the kthread will be scheduled. This will improve performance of crypto operations using crypto engine. Signed-off-by: Tero Kristo

[PATCHv2 15/27] ARM: dts: DRA7: Add DT node for DES IP

From: Joel Fernandes DRA7xx SoCs have a DES3DES IP. Add DT data for the same. Signed-off-by: Joel Fernandes --- arch/arm/boot/dts/dra7.dtsi | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi

[PATCHv2 13/27] crypto: omap-aes: fix crypto engine initialization order

The crypto engine must be initialized before registering algorithms, otherwise the test manager will crash as it attempts to execute tests for the algos while they are being registered. Fixes: 0529900a01cb ("crypto: omap-aes - Support crypto engine framework") Signed-off-by: Tero Kristo

[PATCHv2 06/27] crypto: ahash: increase the maximum allowed statesize

The statesize is used to determine the maximum size for saved ahash context. In some cases, this can be much larger than what is currently allocated for it, for example omap-sham driver uses a buffer size of PAGE_SIZE. Increase the statesize to accommodate this. Signed-off-by: Tero Kristo

Re: [PATCH v4 0/5] /dev/random - a new approach

Am Mittwoch, 22. Juni 2016, 08:54:16 schrieb Austin S. Hemmelgarn: Hi Austin, > You're not demonstrating it's inherently present in the architecture, I am not demonstrating it, interesting statement. I take different arches from different vendors which were developed independently from each

[PATCHv2 05/27] crypto: omap-sham: avoid executing tasklet where not needed

Some of the call paths of OMAP SHA driver can avoid executing the next step of the crypto queue under tasklet; instead, execute the next step directly via function call. This avoids a costly round-trip via the scheduler giving a slight performance boost. Signed-off-by: Tero Kristo

[PATCHv2 20/27] ARM: dts: AM43xx: Add node for RNG

From: Lokesh Vutla Adding DT node for hardware random number generator. Signed-off-by: Lokesh Vutla --- arch/arm/boot/dts/am4372.dtsi | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm/boot/dts/am4372.dtsi

[PATCHv2 10/27] crypto: omap-aes: Add support for multiple cores

From: Lokesh Vutla Some SoCs like omap4/omap5/dra7 contain multiple AES crypto accelerator cores. Adapt the driver to support this. The driver picks the last used device from a list of AES devices. Signed-off-by: Lokesh Vutla [t-kri...@ti.com: forward

[PATCHv2 17/27] ARM: dts: DRA7: Add support for SHA IP

From: Lokesh Vutla DRA7 SoC has the same SHA IP as OMAP5. Add DT entry for the same. Signed-off-by: Lokesh Vutla [t-kri...@ti.com: changed SHA to use EDMA instead of SDMA] Signed-off-by: Tero Kristo --- arch/arm/boot/dts/dra7.dtsi | 11

[PATCHv2 19/27] ARM: dts: AM43xx: clk: Add RNG clk node

From: Lokesh Vutla Add clk node for RNG module. Signed-off-by: Lokesh Vutla --- arch/arm/boot/dts/am43xx-clocks.dtsi | 8 drivers/clk/ti/clk-43xx.c| 1 + 2 files changed, 9 insertions(+) diff --git

[PATCHv2 16/27] ARM: dts: DRA7: Add DT nodes for AES IP

From: Joel Fernandes DRA7 SoC has the same AES IP as OMAP4. Add DT entries for both AES cores. Signed-off-by: Joel Fernandes Signed-off-by: Lokesh Vutla [t-kri...@ti.com: squashed in the change to use EDMA, squashed in support

[PATCHv2 21/27] ARM: DRA7: hwmod: Add data for DES IP

From: Joel Fernandes DRA7 SoC contains DES crypto hardware accelerator. Add hwmod data for this IP so that it can be utilized by crypto frameworks. Signed-off-by: Joel Fernandes Signed-off-by: Lokesh Vutla Signed-off-by: Tero Kristo

[PATCHv2 25/27] ARM: OMAP: DRA7xx: Make L4SEC clock domain SWSUP only

From: Joel Fernandes Using HWSUP for l4sec clock domain is causing warnings in HWMOD code for DRA7. Based on some observations, once the clock domain goes into an IDLE state (because of no activity etc), the IDLEST for the module goes to '0x2' value which means Interface IDLE

[PATCHv2 23/27] ARM: DRA7: hwmod: Add data for SHA IP

From: Lokesh Vutla DRA7 SoC contains SHA crypto hardware accelerator. Add hwmod data for this IP so that it can be utilized by crypto frameworks. Signed-off-by: Lokesh Vutla Signed-off-by: Tero Kristo ---

[PATCHv2 24/27] ARM: DRA7: hwmod: Add data for RNG IP

From: Joel Fernandes DRA7 SoC contains hardware random number generator. Add hwmod data for this IP so that it can be utilized. Signed-off-by: Joel Fernandes Signed-off-by: Lokesh Vutla [t-kri...@ti.com: squashed the RNG hwmod IP flag fixes from

[PATCHv2 26/27] ARM: AM43xx: hwmod: Add data for DES

From: Lokesh Vutla AM43xx SoC contains DES crypto hardware accelerator. Add hwmod data for this IP so that it can be utilized by crypto frameworks. Signed-off-by: Lokesh Vutla Signed-off-by: Tero Kristo ---

[PATCHv2 22/27] ARM: DRA7: hwmod: Add data for AES IP

From: Joel Fernandes DRA7 SoC contains AES crypto hardware accelerator. Add hwmod data for this IP so that it can be utilized by crypto frameworks. Signed-off-by: Joel Fernandes Signed-off-by: Lokesh Vutla [t-kri...@ti.com: squash in support for

[PATCHv2 18/27] ARM: dts: DRA7: Add DT node for RNG IP

From: Lokesh Vutla Adding dt node for hardware random number generator IP. Signed-off-by: Lokesh Vutla --- arch/arm/boot/dts/dra7.dtsi | 9 + 1 file changed, 9 insertions(+) diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi

[PATCHv2 09/27] crypto: omap-aes - Fix enabling clocks

From: Lokesh Vutla Enable clocks for all cores before starting session. Driver has to pic the aes core dynamically based on the queue length. Signed-off-by: Lokesh Vutla --- drivers/crypto/omap-aes.c | 23 +++ 1 file changed, 7

[PATCHv2 00/27] crypto: fixes for omap family of devices

Hi, Changes compared to v1 of the series: - dropped first patch from the series (crypto: omap-aes: Fix registration of algorithms) as it was queued by Herbert already - modified the second (now first) patch of the series to use runtime auto- suspend instead of getting static sync over a cra

[PATCHv2 04/27] crypto: omap-sham: set sw fallback to 240 bytes

From: Bin Liu Adds software fallback support for small crypto requests. In these cases, it is undesirable to use DMA, as setting it up itself is rather heavy operation. Gives about 40% extra performance in ipsec usecase. Signed-off-by: Bin Liu [t-kri...@ti.com:

[PATCHv2 07/27] crypto: omap-sham: implement context export/import APIs

Context export/import are now required for ahash algorithms due to required support in algif_hash. Implement these for OMAP SHA driver, saving and restoring the internal state of the driver. Signed-off-by: Tero Kristo --- drivers/crypto/omap-sham.c | 40

[PATCHv2 01/27] crypto: omap-sham: use runtime_pm autosuspend for clock handling

Calling runtime PM API for every block causes serious performance hit to crypto operations that are done on a long buffer. As crypto is performed on a page boundary, encrypting large buffers can cause a series of crypto operations divided by page. The runtime PM API is also called those many

[PATCHv2 03/27] crypto: omap: do not call dmaengine_terminate_all

From: Lokesh Vutla The extra call to dmaengine_terminate_all is not needed, as the DMA is not running at this point. This improves performance slightly. Signed-off-by: Lokesh Vutla Signed-off-by: Tero Kristo ---

[PATCHv2 02/27] crypto: omap-sham: change queue size from 1 to 10

Change crypto queue size from 1 to 10 for omap SHA driver. This should allow clients to enqueue requests more effectively to avoid serializing whole crypto sequences, giving extra performance. Signed-off-by: Tero Kristo --- drivers/crypto/omap-sham.c | 2 +- 1 file changed, 1

Re: [PATCH v4 0/5] /dev/random - a new approach

On 2016-06-22 01:16, Stephan Mueller wrote: Am Dienstag, 21. Juni 2016, 15:31:07 schrieb Austin S. Hemmelgarn: Hi Austin, Little data, interesting statement for results on 200+ systems including all major CPU arches all showing information leading in the same directions. Let me try

Re: [PATCH v10 2/3] crypto: kpp - Add DH software implementation

On Wed, Jun 22, 2016 at 10:06:32AM +, Benedetto, Salvatore wrote: > > It is pointless because it will only be used for the testmanager. > I can merge the test functions but I'll still have two set_secret functions > based on the alg value. Would that be enough for you? I have made myself

crypto: rsa - Do not gratuitously drop leading zeroes

This was prompted by the caam RSA submission where a lot of work was done just to strip the RSA output of leading zeroes. This is in fact completely pointless because the only user of RSA in the kernel then promptly puts them back. This patch series resolves this madness by simply leaving any

[PATCH 4/8] crypto: rsa-pkcs1pad - Require hash to be present

The only user of rsa-pkcs1pad always uses the hash so there is no reason to support the case of not having a hash. This patch also changes the digest info lookup so that it is only done once during template instantiation rather than on each operation. Signed-off-by: Herbert Xu

Re: [PATCH v3 02/10] crypto: marvell: Check engine is not already running when enabling a req

Romain Perier wrote: > Add a BUG_ON() call when the driver tries to launch a crypto request > while the engine is still processing the previous one. This replaces > a silent system hang by a verbose kernel panic with the associated > backtrace to let the user

[PATCH 8/8] crypto: rsa-pkcs1pad - Avoid copying output when possible

In the vast majority of cases (2^-32 on 32-bit and 2^-64 on 64-bit) cases, the result from encryption/signing will require no padding. This patch makes these two operations write their output directly to the final destination. Only in the exceedingly rare cases where fixup is needed to we copy

[PATCH 3/8] lib/mpi: Do not do sg_virt

Currently the mpi SG helpers use sg_virt which is completely broken. It happens to work with normal kernel memory but will fail with anything that is not linearly mapped. This patch fixes this by using the SG iterator helpers. Signed-off-by: Herbert Xu ---

[PATCH 2/8] crypto: rsa - Generate fixed-length output

Every implementation of RSA that we have naturally generates output with leading zeroes. The one and only user of RSA, pkcs1pad wants to have those leading zeroes in place, in fact because they are currently absent it has to write those zeroes itself. So we shouldn't be stripping leading zeroes

[PATCH 1/8] crypto: testmgr - Allow leading zeros in RSA

This patch allows RSA implementations to produce output with leading zeroes. testmgr will skip leading zeroes when comparing the output. This patch also tries to make the RSA test function generic enough to potentially handle other akcipher algorithms. Signed-off-by: Herbert Xu

[PATCH 6/8] crypto: rsa-pkcs1pad - Always use GFP_KERNEL

We don't currently support using akcipher in atomic contexts, so GFP_KERNEL should always be used. Signed-off-by: Herbert Xu --- crypto/rsa-pkcs1pad.c | 22 ++ 1 file changed, 6 insertions(+), 16 deletions(-) diff --git

Re: [[PATCH v2] 11/11] hwrng: exynos - fixup IO accesors

On 22/06/16 11:37, Herbert Xu wrote: > Ben Dooks wrote: >> The __raw IO functions are not endian safe, so use the readl_relaxed >> and writel_relaxed versions of these. >> >> Signed-off-by: Ben Dooks > > This patch has already been merged. >

Re: [PATCH v3 02/10] crypto: marvell: Check engine is not already running when enabling a req

Hello, Le 22/06/2016 12:33, Herbert Xu a écrit : Romain Perier wrote: Add a BUG_ON() call when the driver tries to launch a crypto request while the engine is still processing the previous one. This replaces a silent system hang by a verbose kernel panic with

Re: [[PATCH v2] 11/11] hwrng: exynos - fixup IO accesors

Ben Dooks wrote: > The __raw IO functions are not endian safe, so use the readl_relaxed > and writel_relaxed versions of these. > > Signed-off-by: Ben Dooks This patch has already been merged. Cheers, -- Email: Herbert Xu

[PATCH 5/8] crypto: rsa-pkcs1pad - Remove bogus page splitting

The helper pkcs1pad_sg_set_buf tries to split a buffer that crosses a page boundary into two SG entries. This is unnecessary. This patch removes that. Signed-off-by: Herbert Xu --- crypto/rsa-pkcs1pad.c | 19 +-- 1 file changed, 5 insertions(+),

[PATCH 7/8] crypto: rsa-pkcs1pad - Move key size check to setkey

Rather than repeatedly checking the key size on each operation, we should be checking it once when the key is set. Signed-off-by: Herbert Xu --- crypto/rsa-pkcs1pad.c | 56 +++--- 1 file changed, 26 insertions(+), 30

RE: [PATCH v10 2/3] crypto: kpp - Add DH software implementation

> -Original Message- > From: Herbert Xu [mailto:herb...@gondor.apana.org.au] > Sent: Wednesday, June 22, 2016 11:04 AM > To: Benedetto, Salvatore > Cc: linux-crypto@vger.kernel.org > Subject: Re: [PATCH v10 2/3] crypto: kpp - Add DH software implementation

Re: [PATCH v10 2/3] crypto: kpp - Add DH software implementation

On Wed, Jun 22, 2016 at 08:18:42AM +, Benedetto, Salvatore wrote: > > If I have to pack the secret into a bytestream, where do you expect the > endianness > of the sizes to be handled? If I understood you correctly I'll pack them in > little endian, > but when decoding I have to take that

Re: [PATCH 02/28] crypto: omap-sham: Don't idle/start SHA device between Encrypt operations

On 07/06/16 15:24, Grygorii Strashko wrote: On 06/07/2016 02:52 PM, Tero Kristo wrote: On 07/06/16 13:08, Herbert Xu wrote: On Wed, Jun 01, 2016 at 06:03:52PM -0500, Dave Gerlach wrote: On 06/01/2016 04:53 AM, Grygorii Strashko wrote: On 06/01/2016 11:56 AM, Tero Kristo wrote: From: Lokesh

RE: [PATCH v10 2/3] crypto: kpp - Add DH software implementation

Hi Herbert, > -Original Message- > From: Herbert Xu [mailto:herb...@gondor.apana.org.au] > Sent: Wednesday, June 22, 2016 7:41 AM > To: Benedetto, Salvatore > Cc: linux-crypto@vger.kernel.org > Subject: Re: [PATCH v10 2/3] crypto: kpp - Add DH software

Re: [PATCH 23/28] ARM: dts: DRA7: Add DT node for DES IP

* Tero Kristo [160621 10:58]: > > Do you want to pick-up the DTS changes from this revision of series as is or > shall I repost those also? I think the series would require a re-ordering of > posting the DTS changes before the hwmod data. I'll pick the dts changes from this

Re: [PATCH v10 2/3] crypto: kpp - Add DH software implementation

On Wed, Jun 22, 2016 at 06:37:50AM +, Benedetto, Salvatore wrote: > > Can you explain me the benefit in doing so? The less code we have the better. Most of our algorithm types have a single test function, I have seen no reason why kpp should be different. akcipher has been an anomaly and

RE: [PATCH v10 2/3] crypto: kpp - Add DH software implementation

> -Original Message- > From: linux-crypto-ow...@vger.kernel.org [mailto:linux-crypto- > ow...@vger.kernel.org] On Behalf Of Herbert Xu > Sent: Wednesday, June 22, 2016 1:51 AM > To: Benedetto, Salvatore > Cc: linux-crypto@vger.kernel.org > Subject: Re: