* Re: [PATCH 2/4] crypto: omap-sham: Add OMAP5/AM43XX SHAM Support
From: Mark Rutland @ 2013-08-09 15:31 UTC (permalink / raw)
To: Lokesh Vutla
Cc: linux-crypto@vger.kernel.org, linux-omap@vger.kernel.org,
joelf@ti.com, rnayak@ti.com, nsekhar@ti.com,
herbert@gondor.hengli.com.au, davem@davemloft.net,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1374821957-30141-3-git-send-email-lokeshvutla@ti.com>
On Fri, Jul 26, 2013 at 07:59:15AM +0100, Lokesh Vutla wrote:
> Add support for the OMAP5 version of the SHAM module
> that is present on OMAP5 and AM43xx SoCs.
>
> This module is very simialar to OMAP4 version of SHAM module,
> and adds SHA384 SHA512 hardware-accelerated hash functions to it.
> To handle the higher digest size of SHA512, few SHA512_DIGEST_i
> (i=1-16, and first 8 registers are duplicated from SHA_DIGEST_i
> registers) registers are added at the end of register set.
> So adding the above register offsets and module info in pdata.
>
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> ---
> drivers/crypto/omap-sham.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 44 insertions(+)
>
> + {
> + .compatible = "ti,omap5-sham",
> + .data = &omap_sham_pdata_omap5,
> + },
No binding update?
Mark.
^ permalink raw reply
* Re: Questions about the Crypto API
From: Marcelo Cerri @ 2013-08-09 12:55 UTC (permalink / raw)
To: Herbert Xu; +Cc: Herbert Xu, linux-crypto@vger.kernel.org
In-Reply-To: <065BBB7616BCE543832A2EF096986B940A05ADCD@039-SN2MPN1-011.039d.mgd.msft.net>
On Thu, Aug 08, 2013 at 02:50:41PM +0000, Garg Vakul-B16394 wrote:
> Hi Herbert
>
>
> > -----Original Message-----
> > From: linux-crypto-owner@vger.kernel.org [mailto:linux-crypto-
> > owner@vger.kernel.org] On Behalf Of Herbert Xu
> > Sent: Tuesday, August 06, 2013 12:30 PM
> > To: Marcelo Cerri
> > Cc: linux-crypto@vger.kernel.org
> > Subject: Re: Questions about the Crypto API
> >
> > On Mon, Aug 05, 2013 at 05:25:57PM -0300, Marcelo Cerri wrote:
> > >
> > > My first doubt is regarding which kind of concurrency the Crypto API
> > > allows. For example, can a single `struct crypto_tfm` be used by two
> > > concurrent calls? I'm asking about that because I noticed that for
> >
> > Yes.
> >
>
> In this post, you mentioned that tfm is single threaded.
> Am I misinterpreting your statement?
>
> http://www.mail-archive.com/linux-crypto@vger.kernel.org/msg08689.html
>
Hi Herbert,
I also would like to better understand that. It doesn't seem natural for
me that a single tfm can be used by multiple kernel threads.
Best regards,
Marcelo
^ permalink raw reply
* [PATCH 2/2] crypto: crypto4xx - Staticize local symbols
From: Jingoo Han @ 2013-08-09 7:59 UTC (permalink / raw)
To: 'Herbert Xu'
Cc: 'David S. Miller', linux-crypto, 'James Hsiao',
Jingoo Han
These local symbols are used only in this file.
Fix the following sparse warnings:
drivers/crypto/amcc/crypto4xx_alg.c:35:6: warning: symbol 'set_dynamic_sa_command_0' was not declared. Should it be static?
drivers/crypto/amcc/crypto4xx_alg.c:55:6: warning: symbol 'set_dynamic_sa_command_1' was not declared. Should it be static?
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/crypto/amcc/crypto4xx_alg.c | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/crypto/amcc/crypto4xx_alg.c b/drivers/crypto/amcc/crypto4xx_alg.c
index a33243c..4afca39 100644
--- a/drivers/crypto/amcc/crypto4xx_alg.c
+++ b/drivers/crypto/amcc/crypto4xx_alg.c
@@ -32,10 +32,10 @@
#include "crypto4xx_sa.h"
#include "crypto4xx_core.h"
-void set_dynamic_sa_command_0(struct dynamic_sa_ctl *sa, u32 save_h,
- u32 save_iv, u32 ld_h, u32 ld_iv, u32 hdr_proc,
- u32 h, u32 c, u32 pad_type, u32 op_grp, u32 op,
- u32 dir)
+static void set_dynamic_sa_command_0(struct dynamic_sa_ctl *sa, u32 save_h,
+ u32 save_iv, u32 ld_h, u32 ld_iv,
+ u32 hdr_proc, u32 h, u32 c, u32 pad_type,
+ u32 op_grp, u32 op, u32 dir)
{
sa->sa_command_0.w = 0;
sa->sa_command_0.bf.save_hash_state = save_h;
@@ -52,9 +52,10 @@ void set_dynamic_sa_command_0(struct dynamic_sa_ctl *sa, u32 save_h,
sa->sa_command_0.bf.dir = dir;
}
-void set_dynamic_sa_command_1(struct dynamic_sa_ctl *sa, u32 cm, u32 hmac_mc,
- u32 cfb, u32 esn, u32 sn_mask, u32 mute,
- u32 cp_pad, u32 cp_pay, u32 cp_hdr)
+static void set_dynamic_sa_command_1(struct dynamic_sa_ctl *sa, u32 cm,
+ u32 hmac_mc, u32 cfb, u32 esn,
+ u32 sn_mask, u32 mute, u32 cp_pad,
+ u32 cp_pay, u32 cp_hdr)
{
sa->sa_command_1.w = 0;
sa->sa_command_1.bf.crypto_mode31 = (cm & 4) >> 2;
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/2] crypto: sahara - Staticize local symbol
From: Jingoo Han @ 2013-08-09 7:57 UTC (permalink / raw)
To: Herbert Xu
Cc: David S. Miller, linux-crypto, 'Javier Martin',
Jingoo Han
This local symbol is used only in this file.
Fix the following sparse warnings:
drivers/crypto/sahara.c:420:6: warning: symbol 'sahara_watchdog' was not declared. Should it be static?
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/crypto/sahara.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/sahara.c b/drivers/crypto/sahara.c
index c3dc1c0..b076d81 100644
--- a/drivers/crypto/sahara.c
+++ b/drivers/crypto/sahara.c
@@ -417,7 +417,7 @@ static void sahara_aes_done_task(unsigned long data)
dev->req->base.complete(&dev->req->base, dev->error);
}
-void sahara_watchdog(unsigned long data)
+static void sahara_watchdog(unsigned long data)
{
struct sahara_dev *dev = (struct sahara_dev *)data;
unsigned int err = sahara_read(dev, SAHARA_REG_ERRSTATUS);
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH v2] drivers/crypto/nx: saves chaining value from co-processor
From: Herbert Xu @ 2013-08-09 6:43 UTC (permalink / raw)
To: Fionnuala Gunter; +Cc: linux-kernel, linux-crypto, linuxppc-dev, mhcerri
In-Reply-To: <1375917350.16050.14.camel@what-is-leg>
On Wed, Aug 07, 2013 at 06:15:50PM -0500, Fionnuala Gunter wrote:
> This patch fixes a bug that is triggered when cts(cbc(aes)) is used with
> nx-crypto driver on input larger than 32 bytes.
>
> The chaining value from co-processor was not being saved. This value is
> needed because it is used as the IV by cts(cbc(aes)).
>
> Signed-off-by: Fionnuala Gunter <fin@linux.vnet.ibm.com>
> Reviewed-by: Marcelo Cerri <mhcerri@linux.vnet.ibm.com>
> ---
> v2. changed signed-off-by to reviewed-by and added more details to
> description
>
> This bug appeared in the original submission (v3.5)
Patch applied. However your patch was totally white-space damaged.
I've fixed it this time, but please fix this in your future
submissions.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 0/6] hwrng: OMAP: Updates for OMAP RNG module
From: Herbert Xu @ 2013-08-09 6:42 UTC (permalink / raw)
To: Lokesh Vutla; +Cc: linux-omap, linux-arm-kernel, mpm, dsaxena, linux-crypto
In-Reply-To: <1375714043-23407-1-git-send-email-lokeshvutla@ti.com>
On Mon, Aug 05, 2013 at 08:17:17PM +0530, Lokesh Vutla wrote:
> This patch series adds support for OMAP4 version of RNG module.
> This module produce a 64 bit random number and also allows to
> de tune FROs when repeated pattern is coming out of FROs.
> This series also has few fixes for the driver.
>
> Lokesh Vutla (6):
> hwrng: OMAP: Use module_platform_driver macro
> hwrng: OMAP: Convert to devm_kzalloc()
> hwrng: OMAP: Remove duplicated function call
> hwrng: OMAP: Add device tree support
> ARM: OMAP2+: Only manually add hwmod data when DT not used.
> hwrng: OMAP: Add OMAP4 TRNG support
All applied. Thanks!
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v2 0/2] drivers/crypto/nx: fixes when input data is too large
From: Herbert Xu @ 2013-08-09 6:42 UTC (permalink / raw)
To: Marcelo Cerri; +Cc: benh, linux-kernel, linux-crypto, linuxppc-dev
In-Reply-To: <1375445392-16237-1-git-send-email-mhcerri@linux.vnet.ibm.com>
On Fri, Aug 02, 2013 at 12:09:50PM +0000, Marcelo Cerri wrote:
> This series of patches fixes two bugs that are triggered when the input data is
> too large. The first one is caused by the miscalculation of physical addresses
> and the second one by some limits that the co-processor has to the input data.
>
> Changes in v2:
> * Replace Signed-Off-By tags with Reviewed-By tags where it is
> appropriate.
>
> Marcelo Cerri (2):
> drivers/crypto/nx: fix physical addresses added to sg lists
> drivers/crypto/nx: fix limits to sg lists for SHA-2
Both patches applied. Thanks!
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v2] drivers/crypto/nx: saves chaining value from co-processor
From: Herbert Xu @ 2013-08-09 6:30 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Fionnuala Gunter, linux-kernel, linux-crypto, linuxppc-dev,
mhcerri
In-Reply-To: <1376029504.32100.16.camel@pasglop>
On Fri, Aug 09, 2013 at 04:25:04PM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2013-08-07 at 18:15 -0500, Fionnuala Gunter wrote:
> > This patch fixes a bug that is triggered when cts(cbc(aes)) is used with
> > nx-crypto driver on input larger than 32 bytes.
> >
> > The chaining value from co-processor was not being saved. This value is
> > needed because it is used as the IV by cts(cbc(aes)).
> >
> > Signed-off-by: Fionnuala Gunter <fin@linux.vnet.ibm.com>
> > Reviewed-by: Marcelo Cerri <mhcerri@linux.vnet.ibm.com>
>
> Herbert, I assume you will handle this along with all the other NX fixes
> and I can safely take them out of linuxppc patchwork ?
Yes of course.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v2] drivers/crypto/nx: saves chaining value from co-processor
From: Benjamin Herrenschmidt @ 2013-08-09 6:25 UTC (permalink / raw)
To: Fionnuala Gunter
Cc: linux-kernel, linux-crypto, linuxppc-dev, herbert, mhcerri
In-Reply-To: <1375917350.16050.14.camel@what-is-leg>
On Wed, 2013-08-07 at 18:15 -0500, Fionnuala Gunter wrote:
> This patch fixes a bug that is triggered when cts(cbc(aes)) is used with
> nx-crypto driver on input larger than 32 bytes.
>
> The chaining value from co-processor was not being saved. This value is
> needed because it is used as the IV by cts(cbc(aes)).
>
> Signed-off-by: Fionnuala Gunter <fin@linux.vnet.ibm.com>
> Reviewed-by: Marcelo Cerri <mhcerri@linux.vnet.ibm.com>
Herbert, I assume you will handle this along with all the other NX fixes
and I can safely take them out of linuxppc patchwork ?
Cheers,
Ben.
> ---
> v2. changed signed-off-by to reviewed-by and added more details to
> description
>
> This bug appeared in the original submission (v3.5)
> ---
> drivers/crypto/nx/nx-aes-cbc.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/crypto/nx/nx-aes-cbc.c
> b/drivers/crypto/nx/nx-aes-cbc.c
> index 35d483f..a2f99a9 100644
> --- a/drivers/crypto/nx/nx-aes-cbc.c
> +++ b/drivers/crypto/nx/nx-aes-cbc.c
> @@ -95,6 +95,7 @@ static int cbc_aes_nx_crypt(struct blkcipher_desc
> *desc,
> if (rc)
> goto out;
>
> + memcpy(desc->info, csbcpb->cpb.aes_cbc.cv, AES_BLOCK_SIZE);
> atomic_inc(&(nx_ctx->stats->aes_ops));
> atomic64_add(csbcpb->csb.processed_byte_count,
> &(nx_ctx->stats->aes_bytes));
^ permalink raw reply
* Re: [PATCH 0/3] ARM: dts: mxs: dcp cleanup patches
From: Kumar Gala @ 2013-08-08 21:14 UTC (permalink / raw)
To: Lothar Waßmann
Cc: devicetree, linux-crypto, Tobias Rauter, Stephen Warren,
Rob Herring, linux-arm-kernel
In-Reply-To: <1375968629-10091-1-git-send-email-LW@KARO-electronics.de>
On Aug 8, 2013, at 8:30 AM, Lothar Waßmann wrote:
> This patch series does the following:
>
> - let the driver be "disabled" by default in imx28.dtsi
> - coding style cleanups in drivers/crypto/dcp.c
> - use the "official" 'fsl,' prefix in the 'compatible' property
>
> The last patch adds a new entry to the of_match_table of the driver,
> so that current DT blobs will still work. When out of tree users
> (mentioned in the commit log of 519d8b1a "Added support for
> Freescale's DCP co-processor") have updated their DTBs the old entry
> 'fsl-dsp' can be removed from the driver.
>
> This patch series requires at least
> "[PATCH 2/8] ARM: dts: mxs: add labels to most nodes for easier reference"
> from the patch series:
> <1375966287-6784-1-git-send-email-LW@KARO-electronics.de> to be
> applied.
>
> arch/arm/boot/dts/imx28.dtsi | 2 +-
> b/arch/arm/boot/dts/imx28-evk.dts | 4 ++++
> b/arch/arm/boot/dts/imx28.dtsi | 3 ++-
> b/drivers/crypto/dcp.c | 11 +++++------
> drivers/crypto/dcp.c | 2 ++
> 5 files changed, 14 insertions(+), 8 deletions(-)
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Is there an actual binding spec for fsl,dcp? If not, there really should be.
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* Re: [PATCH 3/3] crypto: dcp: rename 'compatible' property to 'fsl,dcp'
From: Sergei Shtylyov @ 2013-08-08 19:39 UTC (permalink / raw)
To: Lothar Waßmann
Cc: devicetree, Stephen Warren, Rob Herring, linux-crypto,
Tobias Rauter, linux-arm-kernel
In-Reply-To: <1375968629-10091-4-git-send-email-LW@KARO-electronics.de>
Hello.
On 08/08/2013 05:30 PM, Lothar Waßmann wrote:
> Leave the old 'fsl-dcp' value in place with an appropriate comment
> until external users have updated their DTBs.
> Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
> ---
> arch/arm/boot/dts/imx28.dtsi | 2 +-
> drivers/crypto/dcp.c | 2 ++
> 2 files changed, 3 insertions(+), 1 deletions(-)
> diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
> index ea99d09..0584935 100644
> --- a/arch/arm/boot/dts/imx28.dtsi
> +++ b/arch/arm/boot/dts/imx28.dtsi
> @@ -794,7 +794,7 @@
> };
>
> dcp: dcp@80028000 {
By the way, I see that this is a crypto device, so it should be named
"crypto" according to ePAPR spec. [1]
> - compatible = "fsl-dcp";
> + compatible = "fsl,dcp";
> reg = <0x80028000 0x2000>;
> interrupts = <52 53 54>;
> status = "disabled";
[1] http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf
WBR, Sergei
^ permalink raw reply
* RE: Questions about the Crypto API
From: Garg Vakul-B16394 @ 2013-08-08 14:50 UTC (permalink / raw)
To: Herbert Xu, Marcelo Cerri; +Cc: linux-crypto@vger.kernel.org
In-Reply-To: <20130806070010.GB19754@gondor.apana.org.au>
Hi Herbert
> -----Original Message-----
> From: linux-crypto-owner@vger.kernel.org [mailto:linux-crypto-
> owner@vger.kernel.org] On Behalf Of Herbert Xu
> Sent: Tuesday, August 06, 2013 12:30 PM
> To: Marcelo Cerri
> Cc: linux-crypto@vger.kernel.org
> Subject: Re: Questions about the Crypto API
>
> On Mon, Aug 05, 2013 at 05:25:57PM -0300, Marcelo Cerri wrote:
> >
> > My first doubt is regarding which kind of concurrency the Crypto API
> > allows. For example, can a single `struct crypto_tfm` be used by two
> > concurrent calls? I'm asking about that because I noticed that for
>
> Yes.
>
In this post, you mentioned that tfm is single threaded.
Am I misinterpreting your statement?
http://www.mail-archive.com/linux-crypto@vger.kernel.org/msg08689.html
> > blkcipher the only implementation-specific context that can be used is
> > allocated inside the tfm struct.
>
> Both blkcipher and ablkcipher are meant to be fully reentrant.
> So you must take necessary precautions if your implementation is not
> reentrant, e.g., by locking.
>
> > I'm working to fix some bugs in the NX driver (located in
> > drivers/crypto/nx), and one issue that we are facing is that NFS when
> > using Kerberos uses the same tfm with different kthreads. That causes
> > concurrent accesses to the internal data stored into the context and
> > incorrect results.
> >
> > So my question here is: should this type of concurrency be handled by
> > the driver or a caller is not allowed to use the same tfm for
> > concurrent calls?
>
> From what you've said NFS seems to be doing the right thing, so the bug
> would be in the driver.
>
> > My second doubt is regarding the difference between ablkcipher and
> > blkcipher. I do understand their difference from caller's point of
> view.
> > But I'm not sure what are the consequences of implementing a driver
> > using one or another option.
> >
> > For example, can a blkcipher implementation be used asynchronously and
> > vice versa?
>
> In general which model you pick for drivers depend on what your hardware
> looks like. For example, padlock-aes uses the blkcipher model because
> the hardware presents itself through a synchronous CPU instruction, while
> most other drivers use the ablkcipher interface because the underlying
> hardware completes asynchronously.
>
> A blkcipher implementation is always available through both the blkcipher
> and the ablkcipher interface. While an ablkcipher implementaiton can
> only be used through the ablkcipher interface.
>
> Cheers,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au> Home Page:
> http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
> --
> To unsubscribe from this list: send the line "unsubscribe linux-crypto"
> in the body of a message to majordomo@vger.kernel.org More majordomo info
> at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: Questions about the Crypto API
From: Hsieh, Che-Min @ 2013-08-08 14:04 UTC (permalink / raw)
To: Herbert Xu, Marcelo Cerri; +Cc: linux-crypto@vger.kernel.org
In-Reply-To: <20130808050139.GA9636@gondor.apana.org.au>
Thanks for Marcelo and Herbert for the questions and answers.
I have a few more questions related to the same subject of API.
1. In the crypto_async_request, is the list element available to the driver to use? I see most of drivers do "crypto_enqueue_request()" to keep track of the outstanding async requests. The only exception I have seen so far is talitos driver where they implement their FIFO to keep track the outstanding async requests.
2. The async driver simply returns instead of sleep. The requestor of the async request, does wait_for_completion() for the completion callback from driver. Can it be wait_for_completion_interruptible() such as testmgr.c does?
If the sleep can be interruptible, how does driver know the request has been aborted? The request can be still in the driver queue waiting for the hw to finish execution. How is driver aware to dequeue this aborted request? If not, the link list can be corrupted and cause kernel to crash potentially.
Chemin
-----Original Message-----
From: linux-crypto-owner@vger.kernel.org [mailto:linux-crypto-owner@vger.kernel.org] On Behalf Of Herbert Xu
Sent: Thursday, August 08, 2013 1:02 AM
To: Marcelo Cerri
Cc: linux-crypto@vger.kernel.org
Subject: Re: Questions about the Crypto API
On Tue, Aug 06, 2013 at 11:16:12AM -0300, Marcelo Cerri wrote:
> Herbert,
>
> Let me include a few more questions.
>
> There are flags in several structures such as crypto_async_request,
> blkcipher_desc and crypto_tfm. How they are intended to be used?
>
> For example if I want to explicitly make a call that shouldn't sleep,
> should I clear the CRYPTO_TFM_REQ_MAY_SLEEP in one of these structures?
> And in which one?
>
> Since cryptographic methods can be called in softirq contexts, is the
> caller responsible for setting this flag correctly based on the
> context it is running?
Yes, although MAY_SLEEP is mostly used by synchronous implementations since async drivers can simply return instead of sleeping.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 3/3] crypto: dcp: rename 'compatible' property to 'fsl,dcp'
From: Lothar Waßmann @ 2013-08-08 13:30 UTC (permalink / raw)
To: devicetree
Cc: Stephen Warren, Rob Herring, linux-crypto, Tobias Rauter,
linux-arm-kernel, Lothar Waßmann
In-Reply-To: <1375968629-10091-1-git-send-email-LW@KARO-electronics.de>
Leave the old 'fsl-dcp' value in place with an appropriate comment
until external users have updated their DTBs.
Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
---
arch/arm/boot/dts/imx28.dtsi | 2 +-
drivers/crypto/dcp.c | 2 ++
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index ea99d09..0584935 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -794,7 +794,7 @@
};
dcp: dcp@80028000 {
- compatible = "fsl-dcp";
+ compatible = "fsl,dcp";
reg = <0x80028000 0x2000>;
interrupts = <52 53 54>;
status = "disabled";
diff --git a/drivers/crypto/dcp.c b/drivers/crypto/dcp.c
index 6a2495e..72196c0 100644
--- a/drivers/crypto/dcp.c
+++ b/drivers/crypto/dcp.c
@@ -889,6 +889,8 @@ static int dcp_remove(struct platform_device *pdev)
}
static struct of_device_id fs_dcp_of_match[] = {
+ { .compatible = "fsl,dcp", },
+ /* To be removed when the DT blobs referencing this have been updated */
{ .compatible = "fsl-dcp", },
{}
};
--
1.7.2.5
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/3] crypto: dcp - cleanup: commas at end of struct initializers where appropriate
From: Lothar Waßmann @ 2013-08-08 13:30 UTC (permalink / raw)
To: devicetree
Cc: Stephen Warren, Rob Herring, linux-crypto, Tobias Rauter,
linux-arm-kernel, Lothar Waßmann
In-Reply-To: <1375968629-10091-1-git-send-email-LW@KARO-electronics.de>
Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
---
drivers/crypto/dcp.c | 11 +++++------
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/crypto/dcp.c b/drivers/crypto/dcp.c
index a8a7dd4..6a2495e 100644
--- a/drivers/crypto/dcp.c
+++ b/drivers/crypto/dcp.c
@@ -651,8 +651,7 @@ static struct crypto_alg algs[] = {
.encrypt = dcp_aes_cbc_encrypt,
.decrypt = dcp_aes_cbc_decrypt,
.ivsize = AES_KEYSIZE_128,
- }
-
+ },
},
};
@@ -890,8 +889,8 @@ static int dcp_remove(struct platform_device *pdev)
}
static struct of_device_id fs_dcp_of_match[] = {
- { .compatible = "fsl-dcp"},
- {},
+ { .compatible = "fsl-dcp", },
+ {}
};
static struct platform_driver fs_dcp_driver = {
@@ -900,8 +899,8 @@ static struct platform_driver fs_dcp_driver = {
.driver = {
.name = "fsl-dcp",
.owner = THIS_MODULE,
- .of_match_table = fs_dcp_of_match
- }
+ .of_match_table = fs_dcp_of_match,
+ },
};
module_platform_driver(fs_dcp_driver);
--
1.7.2.5
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/3] ARM: dts: mxs: set dcp to "disabled" by default
From: Lothar Waßmann @ 2013-08-08 13:30 UTC (permalink / raw)
To: devicetree
Cc: Stephen Warren, Rob Herring, linux-crypto, Tobias Rauter,
linux-arm-kernel, Lothar Waßmann
In-Reply-To: <1375968629-10091-1-git-send-email-LW@KARO-electronics.de>
Reintroduce 'status = "disabled"' for the dcp node that was dropped by
commit 519d8b1a "Added support for Freescale's DCP co-processor".
Explicitly enable it in imx28-evk which is referenced in the commit
message of that commit.
Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
---
arch/arm/boot/dts/imx28-evk.dts | 4 ++++
arch/arm/boot/dts/imx28.dtsi | 3 ++-
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/imx28-evk.dts b/arch/arm/boot/dts/imx28-evk.dts
index dff2279..ac790bb 100644
--- a/arch/arm/boot/dts/imx28-evk.dts
+++ b/arch/arm/boot/dts/imx28-evk.dts
@@ -361,3 +361,7 @@
default-brightness-level = <6>;
};
};
+
+&dcp {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index e459d63..ea99d09 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -794,9 +794,10 @@
};
dcp: dcp@80028000 {
+ compatible = "fsl-dcp";
reg = <0x80028000 0x2000>;
interrupts = <52 53 54>;
- compatible = "fsl-dcp";
+ status = "disabled";
};
pxp: pxp@8002a000 {
--
1.7.2.5
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/3] ARM: dts: mxs: dcp cleanup patches
From: Lothar Waßmann @ 2013-08-08 13:30 UTC (permalink / raw)
To: devicetree
Cc: linux-arm-kernel, Tobias Rauter, linux-crypto, Rob Herring,
Stephen Warren
This patch series does the following:
- let the driver be "disabled" by default in imx28.dtsi
- coding style cleanups in drivers/crypto/dcp.c
- use the "official" 'fsl,' prefix in the 'compatible' property
The last patch adds a new entry to the of_match_table of the driver,
so that current DT blobs will still work. When out of tree users
(mentioned in the commit log of 519d8b1a "Added support for
Freescale's DCP co-processor") have updated their DTBs the old entry
'fsl-dsp' can be removed from the driver.
This patch series requires at least
"[PATCH 2/8] ARM: dts: mxs: add labels to most nodes for easier reference"
from the patch series:
<1375966287-6784-1-git-send-email-LW@KARO-electronics.de> to be
applied.
arch/arm/boot/dts/imx28.dtsi | 2 +-
b/arch/arm/boot/dts/imx28-evk.dts | 4 ++++
b/arch/arm/boot/dts/imx28.dtsi | 3 ++-
b/drivers/crypto/dcp.c | 11 +++++------
drivers/crypto/dcp.c | 2 ++
5 files changed, 14 insertions(+), 8 deletions(-)
^ permalink raw reply
* Re: [PATCH v2] drivers/crypto/nx: saves chaining value from co-processor
From: Michael Ellerman @ 2013-08-08 7:49 UTC (permalink / raw)
To: Fionnuala Gunter
Cc: linux-kernel, mhcerri, linuxppc-dev, linux-crypto, herbert
In-Reply-To: <1375917350.16050.14.camel@what-is-leg>
Hi Fin,
I don't know anything about crypto so I can only critique you on your
patch submission technique :) ...
On Wed, Aug 07, 2013 at 06:15:50PM -0500, Fionnuala Gunter wrote:
> This patch fixes a bug that is triggered when cts(cbc(aes)) is used with
> nx-crypto driver on input larger than 32 bytes.
>
> The chaining value from co-processor was not being saved. This value is
> needed because it is used as the IV by cts(cbc(aes)).
>
> Signed-off-by: Fionnuala Gunter <fin@linux.vnet.ibm.com>
> Reviewed-by: Marcelo Cerri <mhcerri@linux.vnet.ibm.com>
> ---
> v2. changed signed-off-by to reviewed-by and added more details to
> description
>
> This bug appeared in the original submission (v3.5)
Ideally this should identify the commit, so:
This bug was introduced in the original submission (v3.5), commit
856d673 "powerpc/crypto: AES-CBC mode routines for nx encryption".
Including the subject of the commit is handy in case the patch has been
backported somewhere, in which case the commit sha will be different.
It should definitely be part of the commit message, not below the "---".
And Ben might disagree but I think with a clear cut bug fix like this it
should include the CC to stable, so:
Cc: stable@vger.kernel.org # 3.5+
cheers
^ permalink raw reply
* Re: Questions about the Crypto API
From: Herbert Xu @ 2013-08-08 5:02 UTC (permalink / raw)
To: Marcelo Cerri; +Cc: linux-crypto
In-Reply-To: <20130806120540.GA364@oc8526070481.ibm.com>
On Tue, Aug 06, 2013 at 09:05:41AM -0300, Marcelo Cerri wrote:
>
> I saw it's possible to keep a context in an ablkcipher_request
> structure. I'm assuming that multiple callers using the same tfm still
> would have to use different requests. So do you think that implementing
> it as an asynchronous block cipher would be an alternative to locks in
> the NX driver?
It really depends on your hardware. For example, does it provide
a convenient way of notifying the completion of an operation?
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Questions about the Crypto API
From: Herbert Xu @ 2013-08-08 5:01 UTC (permalink / raw)
To: Marcelo Cerri; +Cc: linux-crypto
In-Reply-To: <20130806141612.GB364@oc8526070481.ibm.com>
On Tue, Aug 06, 2013 at 11:16:12AM -0300, Marcelo Cerri wrote:
> Herbert,
>
> Let me include a few more questions.
>
> There are flags in several structures such as crypto_async_request,
> blkcipher_desc and crypto_tfm. How they are intended to be used?
>
> For example if I want to explicitly make a call that shouldn't sleep,
> should I clear the CRYPTO_TFM_REQ_MAY_SLEEP in one of these structures?
> And in which one?
>
> Since cryptographic methods can be called in softirq contexts, is the
> caller responsible for setting this flag correctly based on the context
> it is running?
Yes, although MAY_SLEEP is mostly used by synchronous implementations
since async drivers can simply return instead of sleeping.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH v2] drivers/crypto/nx: saves chaining value from co-processor
From: Fionnuala Gunter @ 2013-08-07 23:15 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-crypto, linuxppc-dev, herbert, fin, mhcerri
This patch fixes a bug that is triggered when cts(cbc(aes)) is used with
nx-crypto driver on input larger than 32 bytes.
The chaining value from co-processor was not being saved. This value is
needed because it is used as the IV by cts(cbc(aes)).
Signed-off-by: Fionnuala Gunter <fin@linux.vnet.ibm.com>
Reviewed-by: Marcelo Cerri <mhcerri@linux.vnet.ibm.com>
---
v2. changed signed-off-by to reviewed-by and added more details to
description
This bug appeared in the original submission (v3.5)
---
drivers/crypto/nx/nx-aes-cbc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/crypto/nx/nx-aes-cbc.c
b/drivers/crypto/nx/nx-aes-cbc.c
index 35d483f..a2f99a9 100644
--- a/drivers/crypto/nx/nx-aes-cbc.c
+++ b/drivers/crypto/nx/nx-aes-cbc.c
@@ -95,6 +95,7 @@ static int cbc_aes_nx_crypt(struct blkcipher_desc
*desc,
if (rc)
goto out;
+ memcpy(desc->info, csbcpb->cpb.aes_cbc.cv, AES_BLOCK_SIZE);
atomic_inc(&(nx_ctx->stats->aes_ops));
atomic64_add(csbcpb->csb.processed_byte_count,
&(nx_ctx->stats->aes_bytes));
--
1.7.10.4
^ permalink raw reply related
* Re: Questions about the Crypto API
From: Marcelo Cerri @ 2013-08-06 14:16 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto
In-Reply-To: <20130806120540.GA364@oc8526070481.ibm.com>
Herbert,
Let me include a few more questions.
There are flags in several structures such as crypto_async_request,
blkcipher_desc and crypto_tfm. How they are intended to be used?
For example if I want to explicitly make a call that shouldn't sleep,
should I clear the CRYPTO_TFM_REQ_MAY_SLEEP in one of these structures?
And in which one?
Since cryptographic methods can be called in softirq contexts, is the
caller responsible for setting this flag correctly based on the context
it is running?
Regards,
Marcelo
On Tue, Aug 06, 2013 at 09:05:41AM -0300, Marcelo Cerri wrote:
> Hi Herbert,
>
> Thanks for your answers.
>
> On Tue, Aug 06, 2013 at 05:00:10PM +1000, Herbert Xu wrote:
> > On Mon, Aug 05, 2013 at 05:25:57PM -0300, Marcelo Cerri wrote:
> > >
> > > My first doubt is regarding which kind of concurrency the Crypto API
> > > allows. For example, can a single `struct crypto_tfm` be used by two
> > > concurrent calls? I'm asking about that because I noticed that for
> >
> > Yes.
> >
> > > blkcipher the only implementation-specific context that can be used is
> > > allocated inside the tfm struct.
> >
> > Both blkcipher and ablkcipher are meant to be fully reentrant.
> > So you must take necessary precautions if your implementation
> > is not reentrant, e.g., by locking.
>
> I was considering a spin lock for that, since the cryptographic
> functions can be called from a softirq context. However I don't consider
> a lock a good solution because that could be done without any locks if
> it was possible to keep the current state separated for each operation
> in progress.
>
> >
> > > I'm working to fix some bugs in the NX driver (located in
> > > drivers/crypto/nx), and one issue that we are facing is that NFS when
> > > using Kerberos uses the same tfm with different kthreads. That causes
> > > concurrent accesses to the internal data stored into the context and
> > > incorrect results.
> > >
> > > So my question here is: should this type of concurrency be handled by
> > > the driver or a caller is not allowed to use the same tfm for concurrent
> > > calls?
> >
> > From what you've said NFS seems to be doing the right thing, so the
> > bug would be in the driver.
> >
> > > My second doubt is regarding the difference between ablkcipher and
> > > blkcipher. I do understand their difference from caller's point of view.
> > > But I'm not sure what are the consequences of implementing a driver
> > > using one or another option.
> > >
> > > For example, can a blkcipher implementation be used asynchronously and
> > > vice versa?
> >
> > In general which model you pick for drivers depend on what your
> > hardware looks like. For example, padlock-aes uses the blkcipher
> > model because the hardware presents itself through a synchronous
> > CPU instruction, while most other drivers use the ablkcipher
> > interface because the underlying hardware completes asynchronously.
> >
> > A blkcipher implementation is always available through both the
> > blkcipher and the ablkcipher interface. While an ablkcipher
> > implementaiton can only be used through the ablkcipher interface.
>
> Now a lot of things start to make sense :P
>
> So is that the reason because some drivers implement an ablkcipher and
> then re-implements the same algorithm as a blkcipher just using a wrapper
> over the asynchronous version?
>
> I saw it's possible to keep a context in an ablkcipher_request
> structure. I'm assuming that multiple callers using the same tfm still
> would have to use different requests. So do you think that implementing
> it as an asynchronous block cipher would be an alternative to locks in
> the NX driver?
>
> Regards,
> Marcelo
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Questions about the Crypto API
From: Marcelo Cerri @ 2013-08-06 12:05 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto
In-Reply-To: <20130806070010.GB19754@gondor.apana.org.au>
Hi Herbert,
Thanks for your answers.
On Tue, Aug 06, 2013 at 05:00:10PM +1000, Herbert Xu wrote:
> On Mon, Aug 05, 2013 at 05:25:57PM -0300, Marcelo Cerri wrote:
> >
> > My first doubt is regarding which kind of concurrency the Crypto API
> > allows. For example, can a single `struct crypto_tfm` be used by two
> > concurrent calls? I'm asking about that because I noticed that for
>
> Yes.
>
> > blkcipher the only implementation-specific context that can be used is
> > allocated inside the tfm struct.
>
> Both blkcipher and ablkcipher are meant to be fully reentrant.
> So you must take necessary precautions if your implementation
> is not reentrant, e.g., by locking.
I was considering a spin lock for that, since the cryptographic
functions can be called from a softirq context. However I don't consider
a lock a good solution because that could be done without any locks if
it was possible to keep the current state separated for each operation
in progress.
>
> > I'm working to fix some bugs in the NX driver (located in
> > drivers/crypto/nx), and one issue that we are facing is that NFS when
> > using Kerberos uses the same tfm with different kthreads. That causes
> > concurrent accesses to the internal data stored into the context and
> > incorrect results.
> >
> > So my question here is: should this type of concurrency be handled by
> > the driver or a caller is not allowed to use the same tfm for concurrent
> > calls?
>
> From what you've said NFS seems to be doing the right thing, so the
> bug would be in the driver.
>
> > My second doubt is regarding the difference between ablkcipher and
> > blkcipher. I do understand their difference from caller's point of view.
> > But I'm not sure what are the consequences of implementing a driver
> > using one or another option.
> >
> > For example, can a blkcipher implementation be used asynchronously and
> > vice versa?
>
> In general which model you pick for drivers depend on what your
> hardware looks like. For example, padlock-aes uses the blkcipher
> model because the hardware presents itself through a synchronous
> CPU instruction, while most other drivers use the ablkcipher
> interface because the underlying hardware completes asynchronously.
>
> A blkcipher implementation is always available through both the
> blkcipher and the ablkcipher interface. While an ablkcipher
> implementaiton can only be used through the ablkcipher interface.
Now a lot of things start to make sense :P
So is that the reason because some drivers implement an ablkcipher and
then re-implements the same algorithm as a blkcipher just using a wrapper
over the asynchronous version?
I saw it's possible to keep a context in an ablkcipher_request
structure. I'm assuming that multiple callers using the same tfm still
would have to use different requests. So do you think that implementing
it as an asynchronous block cipher would be an alternative to locks in
the NX driver?
Regards,
Marcelo
^ permalink raw reply
* Re: Questions about the Crypto API
From: Herbert Xu @ 2013-08-06 7:00 UTC (permalink / raw)
To: Marcelo Cerri; +Cc: linux-crypto
In-Reply-To: <20130805202557.GE5752@oc8526070481.ibm.com>
On Mon, Aug 05, 2013 at 05:25:57PM -0300, Marcelo Cerri wrote:
>
> My first doubt is regarding which kind of concurrency the Crypto API
> allows. For example, can a single `struct crypto_tfm` be used by two
> concurrent calls? I'm asking about that because I noticed that for
Yes.
> blkcipher the only implementation-specific context that can be used is
> allocated inside the tfm struct.
Both blkcipher and ablkcipher are meant to be fully reentrant.
So you must take necessary precautions if your implementation
is not reentrant, e.g., by locking.
> I'm working to fix some bugs in the NX driver (located in
> drivers/crypto/nx), and one issue that we are facing is that NFS when
> using Kerberos uses the same tfm with different kthreads. That causes
> concurrent accesses to the internal data stored into the context and
> incorrect results.
>
> So my question here is: should this type of concurrency be handled by
> the driver or a caller is not allowed to use the same tfm for concurrent
> calls?
>From what you've said NFS seems to be doing the right thing, so the
bug would be in the driver.
> My second doubt is regarding the difference between ablkcipher and
> blkcipher. I do understand their difference from caller's point of view.
> But I'm not sure what are the consequences of implementing a driver
> using one or another option.
>
> For example, can a blkcipher implementation be used asynchronously and
> vice versa?
In general which model you pick for drivers depend on what your
hardware looks like. For example, padlock-aes uses the blkcipher
model because the hardware presents itself through a synchronous
CPU instruction, while most other drivers use the ablkcipher
interface because the underlying hardware completes asynchronously.
A blkcipher implementation is always available through both the
blkcipher and the ablkcipher interface. While an ablkcipher
implementaiton can only be used through the ablkcipher interface.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Questions about the Crypto API
From: Marcelo Cerri @ 2013-08-05 20:25 UTC (permalink / raw)
To: linux-crypto, herbert
Hi,
I'm starting to work on some platform-specific implementations using the
Crypto API. I spent some time reading the available documentation and
mainly the code, but I still have some doubts on how the Crypto API
works and how it should be used.
My first doubt is regarding which kind of concurrency the Crypto API
allows. For example, can a single `struct crypto_tfm` be used by two
concurrent calls? I'm asking about that because I noticed that for
blkcipher the only implementation-specific context that can be used is
allocated inside the tfm struct.
I'm working to fix some bugs in the NX driver (located in
drivers/crypto/nx), and one issue that we are facing is that NFS when
using Kerberos uses the same tfm with different kthreads. That causes
concurrent accesses to the internal data stored into the context and
incorrect results.
So my question here is: should this type of concurrency be handled by
the driver or a caller is not allowed to use the same tfm for concurrent
calls?
My second doubt is regarding the difference between ablkcipher and
blkcipher. I do understand their difference from caller's point of view.
But I'm not sure what are the consequences of implementing a driver
using one or another option.
For example, can a blkcipher implementation be used asynchronously and
vice versa?
Thanks for your help.
Marcelo
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox