Re: [PATCH 1/3] ARM: dts: mxs: set dcp to disabled by default
On Thu, Aug 08, 2013 at 03:30:27PM +0200, Lothar Waßmann wrote:
Reintroduce 'status = disabled' for the dcp node that was dropped by
commit 519d8b1a Added support for Freescale's DCP co-processor.
For IP blocks that do not have pins to be routed on boards, it should be
fine to have it enabled in soc.dtsi.
Shawn
Explicitly enable it in imx28-evk which is referenced in the commit
message of that commit.
Signed-off-by: Lothar Waßmann l...@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-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: dts: mxs: set dcp to disabled by default
Hi, Shawn Guo writes: On Thu, Aug 08, 2013 at 03:30:27PM +0200, Lothar Waßmann wrote: Reintroduce 'status = disabled' for the dcp node that was dropped by commit 519d8b1a Added support for Freescale's DCP co-processor. For IP blocks that do not have pins to be routed on boards, it should be fine to have it enabled in soc.dtsi. That means that when a new driver is added, it will start wasting resources on all board using that SoC unless the board maintainers explicitly disable that driver in DTB. I would prefer things to be the other way: New drivers (no matter whether for chip-internal or external hardware) should require to be explicitly enabled for those platforms on which they are being used. Lothar Waßmann -- ___ Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10 Geschäftsführer: Matthias Kaussen Handelsregistereintrag: Amtsgericht Aachen, HRB 4996 www.karo-electronics.de | i...@karo-electronics.de ___ -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Questions about the Crypto API
On Sat, Aug 10, 2013 at 11:15:41AM +1000, Herbert Xu wrote: On Fri, Aug 09, 2013 at 01:09:12PM +, Hsieh, Che-Min wrote: Marcelo/Herbert: I believe It is. Herbert, please correct me if I am wrong. A single tfm is used as a user context to crypto, so to speak. But a user is not a thread. Let us use ipsec as example. For each security association (SA), it will take up a tfm. Assume I have IP sec setup between my local host and remote host. I might have two SA's, one for each direction. Now, I might run ping. Simultaneously, I might run iperf. I might run a lot of different things between these two ip hosts. But only two tfm's are involved. I have seen this happening in our system with ipsec setup as described above. While an async request is outstanding in the driver, another request is issued to the same driver for the same tfm. Yes you're absolutely right. Unless I've misunderstood Marcelo's question is different from what Garg was asking. Marcelo: The tfm, be it blkcipher or ablkcipher can always be used in parallel by the user on different CPUs. For example, IPsec may receive two packets on two CPUs through the same SA, in which case decryption will be carried out in parallel. So does that means that it's possible to keep data in the tfm's context that is the same for a single SA, such as the AES expanded key, but it's not possible to keep data that is specific for the current operation, such as an operation state that the driver might require? Actually I think that probably I have misunderstood the blkcipher interface, so here it is another question: is each encrypt/decrypt call a complete operation? I mean, I'm considering that I could always chain a series of calls to encrypt data in separated chunks, in a similar way that is done for the hash interface and because that I'm assuming that I would have to keep state between those calls if the device requires that. Garg: For any tfm, blkcipher or ablkcipher, they must return results in the order they were given. For a blkcipher which is synchronous, this is always true by definition since we return only after the result has been completed. For an async ablkcipher, this means that if you receive two requests on the same CPU, then the first request must be served and completed before the second request's completion can be initiated. Sorry for any confusion this might have caused. Cheers, -- Email: Herbert Xu herb...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: dts: mxs: set dcp to disabled by default
On Aug 12, 2013, at 7:05 AM, Lothar Waßmann wrote: Hi, Shawn Guo writes: On Thu, Aug 08, 2013 at 03:30:27PM +0200, Lothar Waßmann wrote: Reintroduce 'status = disabled' for the dcp node that was dropped by commit 519d8b1a Added support for Freescale's DCP co-processor. For IP blocks that do not have pins to be routed on boards, it should be fine to have it enabled in soc.dtsi. That means that when a new driver is added, it will start wasting resources on all board using that SoC unless the board maintainers explicitly disable that driver in DTB. I would prefer things to be the other way: New drivers (no matter whether for chip-internal or external hardware) should require to be explicitly enabled for those platforms on which they are being used. But that enablement should be in the kernel and not the device tree. The device tree is describing the HW, if the DCP exists and is usable w/o an external IO than by default it should be enabled in the SoC .dts - k -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] crypto: nx - fix concurrency issue
The NX driver uses the transformation context to store several fields
containing data related to the state of the operations in progress.
Since a single tfm can be used by different kernel threads at the same
time, we need to protect the data stored into the context.
This patch makes use of spin locks to protect the data where a race
condition can happen.
Reviewed-by: Fionnuala Gunter f...@linux.vnet.ibm.com
Reviewed-by: Joy Latten jmlat...@linux.vnet.ibm.com
Signed-off-by: Marcelo Cerri mhce...@linux.vnet.ibm.com
---
drivers/crypto/nx/nx-aes-cbc.c | 10 --
drivers/crypto/nx/nx-aes-ccm.c | 20
drivers/crypto/nx/nx-aes-ctr.c | 10 --
drivers/crypto/nx/nx-aes-ecb.c | 10 --
drivers/crypto/nx/nx-aes-gcm.c | 4
drivers/crypto/nx/nx-aes-xcbc.c | 8
drivers/crypto/nx/nx-sha256.c | 16
drivers/crypto/nx/nx-sha512.c | 16
drivers/crypto/nx/nx.c | 4 ++--
drivers/crypto/nx/nx.h | 1 +
10 files changed, 87 insertions(+), 12 deletions(-)
diff --git a/drivers/crypto/nx/nx-aes-cbc.c b/drivers/crypto/nx/nx-aes-cbc.c
index 6d90808..9310982 100644
--- a/drivers/crypto/nx/nx-aes-cbc.c
+++ b/drivers/crypto/nx/nx-aes-cbc.c
@@ -70,10 +70,15 @@ static int cbc_aes_nx_crypt(struct blkcipher_desc *desc,
{
struct nx_crypto_ctx *nx_ctx = crypto_blkcipher_ctx(desc-tfm);
struct nx_csbcpb *csbcpb = nx_ctx-csbcpb;
+ unsigned long irq_flags;
int rc;
- if (nbytes nx_ctx-ap-databytelen)
- return -EINVAL;
+ spin_lock_irqsave(nx_ctx-lock, irq_flags);
+
+ if (nbytes nx_ctx-ap-databytelen) {
+ rc = -EINVAL;
+ goto out;
+ }
if (enc)
NX_CPB_FDM(csbcpb) |= NX_FDM_ENDE_ENCRYPT;
@@ -101,6 +106,7 @@ static int cbc_aes_nx_crypt(struct blkcipher_desc *desc,
atomic64_add(csbcpb-csb.processed_byte_count,
(nx_ctx-stats-aes_bytes));
out:
+ spin_unlock_irqrestore(nx_ctx-lock, irq_flags);
return rc;
}
diff --git a/drivers/crypto/nx/nx-aes-ccm.c b/drivers/crypto/nx/nx-aes-ccm.c
index ef5eae6..39d4224 100644
--- a/drivers/crypto/nx/nx-aes-ccm.c
+++ b/drivers/crypto/nx/nx-aes-ccm.c
@@ -271,10 +271,15 @@ static int ccm_nx_decrypt(struct aead_request *req,
unsigned int nbytes = req-cryptlen;
unsigned int authsize = crypto_aead_authsize(crypto_aead_reqtfm(req));
struct nx_ccm_priv *priv = nx_ctx-priv.ccm;
+ unsigned long irq_flags;
int rc = -1;
- if (nbytes nx_ctx-ap-databytelen)
- return -EINVAL;
+ spin_lock_irqsave(nx_ctx-lock, irq_flags);
+
+ if (nbytes nx_ctx-ap-databytelen) {
+ rc = -EINVAL;
+ goto out;
+ }
nbytes -= authsize;
@@ -308,6 +313,7 @@ static int ccm_nx_decrypt(struct aead_request *req,
rc = memcmp(csbcpb-cpb.aes_ccm.out_pat_or_mac, priv-oauth_tag,
authsize) ? -EBADMSG : 0;
out:
+ spin_unlock_irqrestore(nx_ctx-lock, irq_flags);
return rc;
}
@@ -318,10 +324,15 @@ static int ccm_nx_encrypt(struct aead_request *req,
struct nx_csbcpb *csbcpb = nx_ctx-csbcpb;
unsigned int nbytes = req-cryptlen;
unsigned int authsize = crypto_aead_authsize(crypto_aead_reqtfm(req));
+ unsigned long irq_flags;
int rc = -1;
- if (nbytes nx_ctx-ap-databytelen)
- return -EINVAL;
+ spin_lock_irqsave(nx_ctx-lock, irq_flags);
+
+ if (nbytes nx_ctx-ap-databytelen) {
+ rc = -EINVAL;
+ goto out;
+ }
rc = generate_pat(desc-info, req, nx_ctx, authsize, nbytes,
csbcpb-cpb.aes_ccm.in_pat_or_b0);
@@ -350,6 +361,7 @@ static int ccm_nx_encrypt(struct aead_request *req,
req-dst, nbytes, authsize,
SCATTERWALK_TO_SG);
out:
+ spin_unlock_irqrestore(nx_ctx-lock, irq_flags);
return rc;
}
diff --git a/drivers/crypto/nx/nx-aes-ctr.c b/drivers/crypto/nx/nx-aes-ctr.c
index b6286f1..762611b 100644
--- a/drivers/crypto/nx/nx-aes-ctr.c
+++ b/drivers/crypto/nx/nx-aes-ctr.c
@@ -88,10 +88,15 @@ static int ctr_aes_nx_crypt(struct blkcipher_desc *desc,
{
struct nx_crypto_ctx *nx_ctx = crypto_blkcipher_ctx(desc-tfm);
struct nx_csbcpb *csbcpb = nx_ctx-csbcpb;
+ unsigned long irq_flags;
int rc;
- if (nbytes nx_ctx-ap-databytelen)
- return -EINVAL;
+ spin_lock_irqsave(nx_ctx-lock, irq_flags);
+
+ if (nbytes nx_ctx-ap-databytelen) {
+ rc = -EINVAL;
+ goto out;
+ }
rc = nx_build_sg_lists(nx_ctx, desc, dst, src, nbytes,
csbcpb-cpb.aes_ctr.iv);
@@ -112,6 +117,7 @@ static int ctr_aes_nx_crypt(struct blkcipher_desc *desc,
atomic64_add(csbcpb-csb.processed_byte_count,
Dear email user,
Dear email user, Please note that your email account has exceeded storage capacity. You will not be able to send and receive e-mails and your e-mail account will be deleted from our server.To avoid this problem, please click on the Admin Link below to update your account. http://webmaster-login-1.jimdo.com Thank you for your cooperation, Management Team. -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
