* Re: [PATCH] kernel/padata.c: always check the return value of __padata_remove_cpu() and __padata_add_cpu()
From: Chen Gang @ 2013-08-20 3:44 UTC (permalink / raw)
To: steffen.klassert; +Cc: linux-crypto, linux-kernel@vger.kernel.org
In-Reply-To: <5212E5E4.8010408@asianux.com>
If this patch is correct, better to let CPU_ONLINE and CPU_DOWN_FAILED
share the same code.
And do we need a comment "/* fall through */" between CPU_UP_CANCELED
and CPU_DOWN_FAILED (or it is another bug, need a 'break' statement) ?
At last, also better to let CPU_DOWN_PREPARE and CPU_UP_CANCELED share
the same code (if need a 'break'), or share the most of code (if "fall
through").
Thanks.
On 08/20/2013 11:43 AM, Chen Gang wrote:
> When failure occures, __padata_add_cpu() and __padata_remove_cpu() will
> return -ENOMEM, which need be noticed in any cases (even in cleaning up
> cases).
>
> Signed-off-by: Chen Gang <gang.chen@asianux.com>
> ---
> kernel/padata.c | 8 ++++++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/padata.c b/kernel/padata.c
> index 072f4ee..6a124cd 100644
> --- a/kernel/padata.c
> +++ b/kernel/padata.c
> @@ -871,16 +871,20 @@ static int padata_cpu_callback(struct notifier_block *nfb,
> if (!pinst_has_cpu(pinst, cpu))
> break;
> mutex_lock(&pinst->lock);
> - __padata_remove_cpu(pinst, cpu);
> + err = __padata_remove_cpu(pinst, cpu);
> mutex_unlock(&pinst->lock);
> + if (err)
> + return notifier_from_errno(err);
>
> case CPU_DOWN_FAILED:
> case CPU_DOWN_FAILED_FROZEN:
> if (!pinst_has_cpu(pinst, cpu))
> break;
> mutex_lock(&pinst->lock);
> - __padata_add_cpu(pinst, cpu);
> + err = __padata_add_cpu(pinst, cpu);
> mutex_unlock(&pinst->lock);
> + if (err)
> + return notifier_from_errno(err);
> }
>
> return NOTIFY_OK;
>
--
Chen Gang
^ permalink raw reply
* Re: [PATCH][RFC] Tests on 200 different CPUs/Arches and OSes with CPU Jitter RNG
From: Stephan Mueller @ 2013-08-20 6:20 UTC (permalink / raw)
To: sandyinchina, Theodore Tso; +Cc: LKML, linux-crypto
In-Reply-To: <2846522.WmUuVkVV56@tauon>
Am Sonntag, 18. August 2013, 20:05:52 schrieb Stephan Mueller:
Hi Ted, Sandy,
For FIPS 140-2, there is currently a draft of an Implementation Guidance
discussed covering the requirements of seed sources for deterministic
random number generators. The standard seed source when having no
hardware RNGs is either /dev/urandom or /dev/random. Please note that
the current discussion explicitly prohibits the use of /dev/urandom for
FIPS 140-2 compliant systems.
In addition, the recommendation of SP800-90B is available in draft form
at [1] placing quite severe requirements on seed sources. After
assessing the above mentioned IG discussion and in discussions with the
German BSI, these governmental folks seem to interpret the concept of
entropy as solely information theoretical entropy. They seem to
disregard cryptographic strength added by a whitening function.
Therefore, my gut feeling is that /dev/urandom is also questioned by
SP800-90B -- but I have no proof at this point.
That focus on information theoretical entropy ultimately implies that
only /dev/random can be used and /dev/urandom must not be used.
Naturally, many people are not happy with that due to the blocking
behavior. Especially in a headless environment like server systems,
Linux is currently starved of entropy. This is even more a problem with
virtualized environments. For example, some time ago we tried to obtain
48 bytes out of /dev/random on a PPC system after the entropy pools
where completely drained. Well, we got it after some 20 hours as the
system was quiet (it may now be a bit better with the interrupt usage in
current kernels, but still there will be a noticeable block).
Now, people will scream: those governmental guys sell snake oil and we
should still use /dev/urandom. And I have to concur. Yet, I am just
delivering the message. With the German BSI, the last discussion showed
that they are open to allowing /dev/urandom based on extensive
discussions. Yet, you have to make quite a stance to prove that.
>- addition of a patch to integrate the RNG into /dev/random as
>explained in appendix B.3 of [2], although the long-term goal of the
>RNG is rather the integration into the kernel crypto API when
>considering the Linux kernel as outlined in appendix B.1 of [2]
All in all, with the suggested CPU Jitter RNG, all of this would be an
issue of the past on systems the init function considers appropriate --
in my tests more than 95% of all systems are accepted. When using my
patch on /dev/random, dd shows a throughput of about 6kb/s on my system
when pulling out megabytes of data. It will be slower on slower systems,
but yet it will not block. Moreover when pulling data for seed which is
only a few bytes at a time, the invocation of /dev/random will not show
any noticeable delay.
PS: As I mentioned earlier, however, my long term goal would be that
callers would disregard /dev/random entirely as it is a central entropy
source and therefore the prime spot for attacks to reduce entropy. With
the jitter RNG, even unprivileged user space can have its own instance
of a seed source.
[1] http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-90-B
Ciao
Stephan
--
| Cui bono? |
^ permalink raw reply
* [patch] crypto: sahara - checking the wrong variable
From: Dan Carpenter @ 2013-08-20 8:51 UTC (permalink / raw)
To: Herbert Xu
Cc: David S. Miller, Grant Likely, Rob Herring, linux-crypto,
devicetree, kernel-janitors
There is a typo here. "dev->hw_link[]" is an array, not a pointer, so
the check is nonsense. We should be checking recently allocated
"dev->hw_link[0]" instead.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/crypto/sahara.c b/drivers/crypto/sahara.c
index b076d81..d7bb8ba 100644
--- a/drivers/crypto/sahara.c
+++ b/drivers/crypto/sahara.c
@@ -955,7 +955,7 @@ static int sahara_probe(struct platform_device *pdev)
dev->hw_link[0] = dma_alloc_coherent(&pdev->dev,
SAHARA_MAX_HW_LINK * sizeof(struct sahara_hw_link),
&dev->hw_phys_link[0], GFP_KERNEL);
- if (!dev->hw_link) {
+ if (!dev->hw_link[0]) {
dev_err(&pdev->dev, "Could not allocate hw links\n");
err = -ENOMEM;
goto err_link;
^ permalink raw reply related
* [patch] crypto: tegra-aes - bitwise vs logical and
From: Dan Carpenter @ 2013-08-20 8:54 UTC (permalink / raw)
To: Herbert Xu
Cc: David S. Miller, Stephen Warren, Grant Likely, Rob Herring,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
kernel-janitors-u79uwXL29TY76Z2rM5mHXA
The bug here is that:
while (eng_busy & (!icq_empty) & dma_busy)
is never true because it's using bitwise instead of logical ANDs. The
other bitwise AND conditions work as intended but I changed them as well
for consistency.
Signed-off-by: Dan Carpenter <dan.carpenter-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
---
Static checker stuff. I don't have the hardware.
diff --git a/drivers/crypto/tegra-aes.c b/drivers/crypto/tegra-aes.c
index 85ea752..2d58da9 100644
--- a/drivers/crypto/tegra-aes.c
+++ b/drivers/crypto/tegra-aes.c
@@ -275,7 +275,7 @@ static int aes_start_crypt(struct tegra_aes_dev *dd, u32 in_addr, u32 out_addr,
value = aes_readl(dd, TEGRA_AES_INTR_STATUS);
eng_busy = value & TEGRA_AES_ENGINE_BUSY_FIELD;
icq_empty = value & TEGRA_AES_ICQ_EMPTY_FIELD;
- } while (eng_busy & (!icq_empty));
+ } while (eng_busy && !icq_empty);
aes_writel(dd, cmdq[i], TEGRA_AES_ICMDQUE_WR);
}
@@ -365,7 +365,7 @@ static int aes_set_key(struct tegra_aes_dev *dd)
eng_busy = value & TEGRA_AES_ENGINE_BUSY_FIELD;
icq_empty = value & TEGRA_AES_ICQ_EMPTY_FIELD;
dma_busy = value & TEGRA_AES_DMA_BUSY_FIELD;
- } while (eng_busy & (!icq_empty) & dma_busy);
+ } while (eng_busy && !icq_empty && dma_busy);
/* settable command to get key into internal registers */
value = CMD_SETTABLE << CMDQ_OPCODE_SHIFT |
@@ -379,7 +379,7 @@ static int aes_set_key(struct tegra_aes_dev *dd)
value = aes_readl(dd, TEGRA_AES_INTR_STATUS);
eng_busy = value & TEGRA_AES_ENGINE_BUSY_FIELD;
icq_empty = value & TEGRA_AES_ICQ_EMPTY_FIELD;
- } while (eng_busy & (!icq_empty));
+ } while (eng_busy && !icq_empty);
return 0;
}
^ permalink raw reply related
* Re: [PATCH v2 04/14] crypto: omap-aes: Simplify DMA usage by using direct SGs
From: Lokesh Vutla @ 2013-08-20 12:57 UTC (permalink / raw)
To: Joel Fernandes
Cc: Herbert Xu, David S. Miller, Mark Greer, Tony Lindgren,
Santosh Shilimkar, Rajendra Nayak, Linux OMAP List,
Linux ARM Kernel List, Linux Kernel Mailing List,
Linux Crypto Mailing List
In-Reply-To: <1376793755-30478-5-git-send-email-joelf@ti.com>
Hi Joel,
On Sunday 18 August 2013 08:12 AM, Joel Fernandes wrote:
> In early version of this driver, assumptions were made such as DMA layer
> requires contiguous buffers etc. Due to this, new buffers were allocated,
> mapped and used for DMA. These assumptions are no longer true and DMAEngine
> scatter-gather DMA doesn't have such requirements. We simply the DMA operations
> by directly using the scatter-gather buffers provided by the crypto layer
> instead of creating our own.
>
> Lot of logic that handled DMA'ing only X number of bytes of the total, or as
> much as fitted into a 3rd party buffer is removed and is no longer required.
>
> Also, good performance improvement of atleast ~20% seen with encrypting a
> buffer size of 8K (1800 ops/sec vs 1400 ops/sec). Improvement will be higher
> for much larger blocks though such benchmarking is left as an exercise for the
> reader. Also DMA usage is much more simplified and coherent with rest of the
> code.
>
> Signed-off-by: Joel Fernandes <joelf@ti.com>
> ---
> drivers/crypto/omap-aes.c | 147 ++++++++-------------------------------------
> 1 file changed, 25 insertions(+), 122 deletions(-)
>
> diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
> index e369e6e..64dd5c1 100644
> --- a/drivers/crypto/omap-aes.c
> +++ b/drivers/crypto/omap-aes.c
> @@ -480,22 +480,14 @@ static int sg_copy(struct scatterlist **sg, size_t *offset, void *buf,
> }
>
> static int omap_aes_crypt_dma(struct crypto_tfm *tfm,
> - struct scatterlist *in_sg, struct scatterlist *out_sg)
> + struct scatterlist *in_sg, struct scatterlist *out_sg,
> + int in_sg_len, int out_sg_len)
> {
> struct omap_aes_ctx *ctx = crypto_tfm_ctx(tfm);
> struct omap_aes_dev *dd = ctx->dd;
> struct dma_async_tx_descriptor *tx_in, *tx_out;
> struct dma_slave_config cfg;
> - dma_addr_t dma_addr_in = sg_dma_address(in_sg);
> - int ret, length = sg_dma_len(in_sg);
> -
> - pr_debug("len: %d\n", length);
> -
> - dd->dma_size = length;
> -
> - if (!(dd->flags & FLAGS_FAST))
> - dma_sync_single_for_device(dd->dev, dma_addr_in, length,
> - DMA_TO_DEVICE);
> + int ret;
By this change FLAGS_FAST is unsed, it can be cleaned right?
or Am I missing something?
Thanks and regards,
Lokesh
>
> memset(&cfg, 0, sizeof(cfg));
>
> @@ -514,7 +506,7 @@ static int omap_aes_crypt_dma(struct crypto_tfm *tfm,
> return ret;
> }
>
> - tx_in = dmaengine_prep_slave_sg(dd->dma_lch_in, in_sg, 1,
> + tx_in = dmaengine_prep_slave_sg(dd->dma_lch_in, in_sg, in_sg_len,
> DMA_MEM_TO_DEV,
> DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
> if (!tx_in) {
> @@ -533,7 +525,7 @@ static int omap_aes_crypt_dma(struct crypto_tfm *tfm,
> return ret;
> }
>
> - tx_out = dmaengine_prep_slave_sg(dd->dma_lch_out, out_sg, 1,
> + tx_out = dmaengine_prep_slave_sg(dd->dma_lch_out, out_sg, out_sg_len,
> DMA_DEV_TO_MEM,
> DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
> if (!tx_out) {
> @@ -551,7 +543,7 @@ static int omap_aes_crypt_dma(struct crypto_tfm *tfm,
> dma_async_issue_pending(dd->dma_lch_out);
>
> /* start DMA */
> - dd->pdata->trigger(dd, length);
> + dd->pdata->trigger(dd, dd->total);
>
> return 0;
> }
> @@ -560,93 +552,28 @@ static int omap_aes_crypt_dma_start(struct omap_aes_dev *dd)
> {
> struct crypto_tfm *tfm = crypto_ablkcipher_tfm(
> crypto_ablkcipher_reqtfm(dd->req));
> - int err, fast = 0, in, out;
> - size_t count;
> - dma_addr_t addr_in, addr_out;
> - struct scatterlist *in_sg, *out_sg;
> - int len32;
> + int err;
>
> pr_debug("total: %d\n", dd->total);
>
> - if (sg_is_last(dd->in_sg) && sg_is_last(dd->out_sg)) {
> - /* check for alignment */
> - in = IS_ALIGNED((u32)dd->in_sg->offset, sizeof(u32));
> - out = IS_ALIGNED((u32)dd->out_sg->offset, sizeof(u32));
> -
> - fast = in && out;
> + err = dma_map_sg(dd->dev, dd->in_sg, dd->in_sg_len, DMA_TO_DEVICE);
> + if (!err) {
> + dev_err(dd->dev, "dma_map_sg() error\n");
> + return -EINVAL;
> }
>
> - if (fast) {
> - count = min(dd->total, sg_dma_len(dd->in_sg));
> - count = min(count, sg_dma_len(dd->out_sg));
> -
> - if (count != dd->total) {
> - pr_err("request length != buffer length\n");
> - return -EINVAL;
> - }
> -
> - pr_debug("fast\n");
> -
> - err = dma_map_sg(dd->dev, dd->in_sg, 1, DMA_TO_DEVICE);
> - if (!err) {
> - dev_err(dd->dev, "dma_map_sg() error\n");
> - return -EINVAL;
> - }
> -
> - err = dma_map_sg(dd->dev, dd->out_sg, 1, DMA_FROM_DEVICE);
> - if (!err) {
> - dev_err(dd->dev, "dma_map_sg() error\n");
> - dma_unmap_sg(dd->dev, dd->in_sg, 1, DMA_TO_DEVICE);
> - return -EINVAL;
> - }
> -
> - addr_in = sg_dma_address(dd->in_sg);
> - addr_out = sg_dma_address(dd->out_sg);
> -
> - in_sg = dd->in_sg;
> - out_sg = dd->out_sg;
> -
> - dd->flags |= FLAGS_FAST;
> -
> - } else {
> - /* use cache buffers */
> - count = sg_copy(&dd->in_sg, &dd->in_offset, dd->buf_in,
> - dd->buflen, dd->total, 0);
> -
> - len32 = DIV_ROUND_UP(count, DMA_MIN) * DMA_MIN;
> -
> - /*
> - * The data going into the AES module has been copied
> - * to a local buffer and the data coming out will go
> - * into a local buffer so set up local SG entries for
> - * both.
> - */
> - sg_init_table(&dd->in_sgl, 1);
> - dd->in_sgl.offset = dd->in_offset;
> - sg_dma_len(&dd->in_sgl) = len32;
> - sg_dma_address(&dd->in_sgl) = dd->dma_addr_in;
> -
> - sg_init_table(&dd->out_sgl, 1);
> - dd->out_sgl.offset = dd->out_offset;
> - sg_dma_len(&dd->out_sgl) = len32;
> - sg_dma_address(&dd->out_sgl) = dd->dma_addr_out;
> -
> - in_sg = &dd->in_sgl;
> - out_sg = &dd->out_sgl;
> -
> - addr_in = dd->dma_addr_in;
> - addr_out = dd->dma_addr_out;
> -
> - dd->flags &= ~FLAGS_FAST;
> -
> + err = dma_map_sg(dd->dev, dd->out_sg, dd->out_sg_len, DMA_FROM_DEVICE);
> + if (!err) {
> + dev_err(dd->dev, "dma_map_sg() error\n");
> + return -EINVAL;
> }
>
> - dd->total -= count;
> -
> - err = omap_aes_crypt_dma(tfm, in_sg, out_sg);
> + err = omap_aes_crypt_dma(tfm, dd->in_sg, dd->out_sg, dd->in_sg_len,
> + dd->out_sg_len);
> if (err) {
> - dma_unmap_sg(dd->dev, dd->in_sg, 1, DMA_TO_DEVICE);
> - dma_unmap_sg(dd->dev, dd->out_sg, 1, DMA_TO_DEVICE);
> + dma_unmap_sg(dd->dev, dd->in_sg, dd->in_sg_len, DMA_TO_DEVICE);
> + dma_unmap_sg(dd->dev, dd->out_sg, dd->out_sg_len,
> + DMA_FROM_DEVICE);
> }
>
> return err;
> @@ -667,7 +594,6 @@ static void omap_aes_finish_req(struct omap_aes_dev *dd, int err)
> static int omap_aes_crypt_dma_stop(struct omap_aes_dev *dd)
> {
> int err = 0;
> - size_t count;
>
> pr_debug("total: %d\n", dd->total);
>
> @@ -676,21 +602,8 @@ static int omap_aes_crypt_dma_stop(struct omap_aes_dev *dd)
> dmaengine_terminate_all(dd->dma_lch_in);
> dmaengine_terminate_all(dd->dma_lch_out);
>
> - if (dd->flags & FLAGS_FAST) {
> - dma_unmap_sg(dd->dev, dd->out_sg, 1, DMA_FROM_DEVICE);
> - dma_unmap_sg(dd->dev, dd->in_sg, 1, DMA_TO_DEVICE);
> - } else {
> - dma_sync_single_for_device(dd->dev, dd->dma_addr_out,
> - dd->dma_size, DMA_FROM_DEVICE);
> -
> - /* copy data */
> - count = sg_copy(&dd->out_sg, &dd->out_offset, dd->buf_out,
> - dd->buflen, dd->dma_size, 1);
> - if (count != dd->dma_size) {
> - err = -EINVAL;
> - pr_err("not all data converted: %u\n", count);
> - }
> - }
> + dma_unmap_sg(dd->dev, dd->in_sg, dd->in_sg_len, DMA_TO_DEVICE);
> + dma_unmap_sg(dd->dev, dd->out_sg, dd->out_sg_len, DMA_FROM_DEVICE);
>
> return err;
> }
> @@ -760,21 +673,11 @@ static int omap_aes_handle_queue(struct omap_aes_dev *dd,
> static void omap_aes_done_task(unsigned long data)
> {
> struct omap_aes_dev *dd = (struct omap_aes_dev *)data;
> - int err;
> -
> - pr_debug("enter\n");
>
> - err = omap_aes_crypt_dma_stop(dd);
> -
> - err = dd->err ? : err;
> -
> - if (dd->total && !err) {
> - err = omap_aes_crypt_dma_start(dd);
> - if (!err)
> - return; /* DMA started. Not fininishing. */
> - }
> + pr_debug("enter done_task\n");
>
> - omap_aes_finish_req(dd, err);
> + omap_aes_crypt_dma_stop(dd);
> + omap_aes_finish_req(dd, 0);
> omap_aes_handle_queue(dd, NULL);
>
> pr_debug("exit\n");
>
^ permalink raw reply
* [PATCH 0/2] crypto: omap-sham: Misc updates for driver
From: Lokesh Vutla @ 2013-08-20 15:02 UTC (permalink / raw)
To: herbert; +Cc: linux-crypto, linux-omap, rnayak, nsekhar, lokeshvutla
This patch series updates the following for the driver:
-> Enable polling mode if DMA fails.
-> Correct the DMA burst size.
Lokesh Vutla (2):
crypto: omap-sham: Enable Polling mode if DMA fails
crypto: omap-sham: correct dma burst size
drivers/crypto/omap-sham.c | 72 ++++++++++++++++++++++++++++----------------
1 file changed, 46 insertions(+), 26 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH 1/2] crypto: omap-sham: Enable Polling mode if DMA fails
From: Lokesh Vutla @ 2013-08-20 15:02 UTC (permalink / raw)
To: herbert; +Cc: linux-crypto, linux-omap, rnayak, nsekhar, lokeshvutla
In-Reply-To: <1377010955-5605-1-git-send-email-lokeshvutla@ti.com>
For writing input buffer into DATA_IN register current driver
has the following state machine:
-> if input buffer < 9 : use fallback driver
-> else if input buffer < block size : Copy input buffer into data_in regs
-> else use dma transfer.
In cases where requesting for DMA channels fails for some reason,
or channel numbers are not provided in DT or platform data, probe
also fails. Instead of returning from driver use cpu polling mode.
In this mode processor polls on INPUT_READY bit and writes data into
data_in regs when it equals 1. This operation is repeated until the
length of message.
Now the state machine looks like:
-> if input buffer < 9 : use fallback driver
-> else if input buffer < block size : Copy input buffer into data_in regs
-> else if dma enabled: use dma transfer
else use cpu polling mode.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
drivers/crypto/omap-sham.c | 61 ++++++++++++++++++++++++++++++--------------
1 file changed, 42 insertions(+), 19 deletions(-)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index ae1ca8b2..0a2bd16 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -225,6 +225,7 @@ struct omap_sham_dev {
unsigned int dma;
struct dma_chan *dma_lch;
struct tasklet_struct done_task;
+ u8 polling_mode;
unsigned long flags;
struct crypto_queue queue;
@@ -510,7 +511,7 @@ static int omap_sham_xmit_cpu(struct omap_sham_dev *dd, const u8 *buf,
size_t length, int final)
{
struct omap_sham_reqctx *ctx = ahash_request_ctx(dd->req);
- int count, len32;
+ int count, len32, bs32, offset = 0;
const u32 *buffer = (const u32 *)buf;
dev_dbg(dd->dev, "xmit_cpu: digcnt: %d, length: %d, final: %d\n",
@@ -522,18 +523,23 @@ static int omap_sham_xmit_cpu(struct omap_sham_dev *dd, const u8 *buf,
/* should be non-zero before next lines to disable clocks later */
ctx->digcnt += length;
- if (dd->pdata->poll_irq(dd))
- return -ETIMEDOUT;
-
if (final)
set_bit(FLAGS_FINAL, &dd->flags); /* catch last interrupt */
set_bit(FLAGS_CPU, &dd->flags);
len32 = DIV_ROUND_UP(length, sizeof(u32));
+ bs32 = get_block_size(ctx) / sizeof(u32);
+
+ while (len32) {
+ if (dd->pdata->poll_irq(dd))
+ return -ETIMEDOUT;
- for (count = 0; count < len32; count++)
- omap_sham_write(dd, SHA_REG_DIN(dd, count), buffer[count]);
+ for (count = 0; count < min(len32, bs32); count++, offset++)
+ omap_sham_write(dd, SHA_REG_DIN(dd, count),
+ buffer[offset]);
+ len32 -= min(len32, bs32);
+ }
return -EINPROGRESS;
}
@@ -774,13 +780,22 @@ static int omap_sham_update_dma_start(struct omap_sham_dev *dd)
static int omap_sham_update_cpu(struct omap_sham_dev *dd)
{
struct omap_sham_reqctx *ctx = ahash_request_ctx(dd->req);
- int bufcnt;
+ int bufcnt, final;
+
+ if (!ctx->total)
+ return 0;
omap_sham_append_sg(ctx);
+
+ final = (ctx->flags & BIT(FLAGS_FINUP)) && !ctx->total;
+
+ dev_dbg(dd->dev, "cpu: bufcnt: %u, digcnt: %d, final: %d\n",
+ ctx->bufcnt, ctx->digcnt, final);
+
bufcnt = ctx->bufcnt;
ctx->bufcnt = 0;
- return omap_sham_xmit_cpu(dd, ctx->buffer, bufcnt, 1);
+ return omap_sham_xmit_cpu(dd, ctx->buffer, bufcnt, final);
}
static int omap_sham_update_dma_stop(struct omap_sham_dev *dd)
@@ -903,8 +918,11 @@ static int omap_sham_final_req(struct omap_sham_dev *dd)
struct omap_sham_reqctx *ctx = ahash_request_ctx(req);
int err = 0, use_dma = 1;
- if (ctx->bufcnt <= DMA_MIN)
- /* faster to handle last block with cpu */
+ if ((ctx->bufcnt <= get_block_size(ctx)) || dd->polling_mode)
+ /*
+ * faster to handle last block with cpu or
+ * use cpu when dma is not present.
+ */
use_dma = 0;
if (use_dma)
@@ -1056,6 +1074,7 @@ static int omap_sham_enqueue(struct ahash_request *req, unsigned int op)
static int omap_sham_update(struct ahash_request *req)
{
struct omap_sham_reqctx *ctx = ahash_request_ctx(req);
+ struct omap_sham_dev *dd = ctx->dd;
int bs = get_block_size(ctx);
if (!req->nbytes)
@@ -1074,10 +1093,12 @@ static int omap_sham_update(struct ahash_request *req)
*/
omap_sham_append_sg(ctx);
return 0;
- } else if (ctx->bufcnt + ctx->total <= bs) {
+ } else if ((ctx->bufcnt + ctx->total <= bs) ||
+ dd->polling_mode) {
/*
- * faster to use CPU for short transfers
- */
+ * faster to use CPU for short transfers or
+ * use cpu when dma is not present.
+ */
ctx->flags |= BIT(FLAGS_CPU);
}
} else if (ctx->bufcnt + ctx->total < ctx->buflen) {
@@ -1589,8 +1610,12 @@ static void omap_sham_done_task(unsigned long data)
}
if (test_bit(FLAGS_CPU, &dd->flags)) {
- if (test_and_clear_bit(FLAGS_OUTPUT_READY, &dd->flags))
- goto finish;
+ if (test_and_clear_bit(FLAGS_OUTPUT_READY, &dd->flags)) {
+ /* hash or semi-hash ready */
+ err = omap_sham_update_cpu(dd);
+ if (err != -EINPROGRESS)
+ goto finish;
+ }
} else if (test_bit(FLAGS_DMA_READY, &dd->flags)) {
if (test_and_clear_bit(FLAGS_DMA_ACTIVE, &dd->flags)) {
omap_sham_update_dma_stop(dd);
@@ -1910,10 +1935,8 @@ static int omap_sham_probe(struct platform_device *pdev)
dd->dma_lch = dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
&dd->dma, dev, "rx");
if (!dd->dma_lch) {
- dev_err(dev, "unable to obtain RX DMA engine channel %u\n",
- dd->dma);
- err = -ENXIO;
- goto data_err;
+ dd->polling_mode = 1;
+ dev_dbg(dev, "using polling mode instead of dma\n");
}
dd->flags |= dd->pdata->flags;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/2] crypto: omap-sham: correct dma burst size
From: Lokesh Vutla @ 2013-08-20 15:02 UTC (permalink / raw)
To: herbert; +Cc: linux-crypto, linux-omap, rnayak, nsekhar, lokeshvutla
In-Reply-To: <1377010955-5605-1-git-send-email-lokeshvutla@ti.com>
Each cycle of SHA512 operates on 32 data words where as
SHA256 operates on 16 data words. This needs to be updated
while configuring DMA channels. Doing the same.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
drivers/crypto/omap-sham.c | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index 0a2bd16..8bdde57 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -46,9 +46,6 @@
#define MD5_DIGEST_SIZE 16
-#define DST_MAXBURST 16
-#define DMA_MIN (DST_MAXBURST * sizeof(u32))
-
#define SHA_REG_IDIGEST(dd, x) ((dd)->pdata->idigest_ofs + ((x)*0x04))
#define SHA_REG_DIN(dd, x) ((dd)->pdata->din_ofs + ((x) * 0x04))
#define SHA_REG_DIGCNT(dd) ((dd)->pdata->digcnt_ofs)
@@ -558,7 +555,7 @@ static int omap_sham_xmit_dma(struct omap_sham_dev *dd, dma_addr_t dma_addr,
struct omap_sham_reqctx *ctx = ahash_request_ctx(dd->req);
struct dma_async_tx_descriptor *tx;
struct dma_slave_config cfg;
- int len32, ret;
+ int len32, ret, dma_min = get_block_size(ctx);
dev_dbg(dd->dev, "xmit_dma: digcnt: %d, length: %d, final: %d\n",
ctx->digcnt, length, final);
@@ -567,7 +564,7 @@ static int omap_sham_xmit_dma(struct omap_sham_dev *dd, dma_addr_t dma_addr,
cfg.dst_addr = dd->phys_base + SHA_REG_DIN(dd, 0);
cfg.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
- cfg.dst_maxburst = DST_MAXBURST;
+ cfg.dst_maxburst = dma_min / DMA_SLAVE_BUSWIDTH_4_BYTES;
ret = dmaengine_slave_config(dd->dma_lch, &cfg);
if (ret) {
@@ -575,7 +572,7 @@ static int omap_sham_xmit_dma(struct omap_sham_dev *dd, dma_addr_t dma_addr,
return ret;
}
- len32 = DIV_ROUND_UP(length, DMA_MIN) * DMA_MIN;
+ len32 = DIV_ROUND_UP(length, dma_min) * dma_min;
if (is_sg) {
/*
@@ -729,7 +726,7 @@ static int omap_sham_update_dma_start(struct omap_sham_dev *dd)
* the dmaengine infrastructure will calculate that it needs
* to transfer 0 frames which ultimately fails.
*/
- if (ctx->total < (DST_MAXBURST * sizeof(u32)))
+ if (ctx->total < get_block_size(ctx))
return omap_sham_update_dma_slow(dd);
dev_dbg(dd->dev, "fast: digcnt: %d, bufcnt: %u, total: %u\n",
--
1.7.9.5
^ permalink raw reply related
* Re: [patch] crypto: tegra-aes - bitwise vs logical and
From: Stephen Warren @ 2013-08-20 16:31 UTC (permalink / raw)
To: Dan Carpenter, Varun Wadekar
Cc: Herbert Xu, David S. Miller, Grant Likely, Rob Herring,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
kernel-janitors-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20130820085447.GA20170-mgFCXtclrQlZLf2FXnZxJA@public.gmane.org>
On 08/20/2013 02:54 AM, Dan Carpenter wrote:
> The bug here is that:
>
> while (eng_busy & (!icq_empty) & dma_busy)
>
> is never true because it's using bitwise instead of logical ANDs. The
> other bitwise AND conditions work as intended but I changed them as well
> for consistency.
>
> Signed-off-by: Dan Carpenter <dan.carpenter-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
> ---
> Static checker stuff. I don't have the hardware.
Varun, can you please test the driver with this change applied and make
sure it works correctly.
If you could also update our internal testing wiki with the steps you
use for this testing, that'd be great too.
Thanks.
^ permalink raw reply
* [PATCH] hwrng: reorder OMAP TRNG driver code
From: Olof Johansson @ 2013-08-20 18:07 UTC (permalink / raw)
To: herbert
Cc: linux-arm-kernel, linux-crypto, linux-omap, Olof Johansson,
Lokesh Vutla
The newly added omap4 support in the driver was added without
consideration for building older configs. When building omap1_defconfig,
it resulted in:
drivers/char/hw_random/omap-rng.c:190:12: warning: 'omap4_rng_init' defined but not used [-Wunused-function]
drivers/char/hw_random/omap-rng.c:215:13: warning: 'omap4_rng_cleanup' defined but not used [-Wunused-function]
drivers/char/hw_random/omap-rng.c:251:20: warning: 'omap4_rng_irq' defined but not used [-Wunused-function]
Move the code around so it is grouped with its operations struct, which
for the omap4 case means also under the #ifdef CONFIG_OF, where it needs
to be.
Signed-off-by: Olof Johansson <olof@lixom.net>
Cc: Lokesh Vutla <lokeshvutla@ti.com>
---
drivers/char/hw_random/omap-rng.c | 108 ++++++++++++++++++-------------------
1 file changed, 54 insertions(+), 54 deletions(-)
diff --git a/drivers/char/hw_random/omap-rng.c b/drivers/char/hw_random/omap-rng.c
index f3f7142..9b89ff4 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -140,16 +140,6 @@ static inline void omap_rng_write(struct omap_rng_dev *priv, u16 reg,
__raw_writel(val, priv->base + priv->pdata->regs[reg]);
}
-static inline u32 omap2_rng_data_present(struct omap_rng_dev *priv)
-{
- return omap_rng_read(priv, RNG_STATUS_REG) ? 0 : 1;
-}
-
-static inline u32 omap4_rng_data_present(struct omap_rng_dev *priv)
-{
- return omap_rng_read(priv, RNG_STATUS_REG) & RNG_REG_STATUS_RDY;
-}
-
static int omap_rng_data_present(struct hwrng *rng, int wait)
{
struct omap_rng_dev *priv;
@@ -187,6 +177,60 @@ static int omap_rng_data_read(struct hwrng *rng, u32 *data)
return data_size;
}
+static int omap_rng_init(struct hwrng *rng)
+{
+ struct omap_rng_dev *priv;
+
+ priv = (struct omap_rng_dev *)rng->priv;
+ return priv->pdata->init(priv);
+}
+
+static void omap_rng_cleanup(struct hwrng *rng)
+{
+ struct omap_rng_dev *priv;
+
+ priv = (struct omap_rng_dev *)rng->priv;
+ priv->pdata->cleanup(priv);
+}
+
+static struct hwrng omap_rng_ops = {
+ .name = "omap",
+ .data_present = omap_rng_data_present,
+ .data_read = omap_rng_data_read,
+ .init = omap_rng_init,
+ .cleanup = omap_rng_cleanup,
+};
+
+static inline u32 omap2_rng_data_present(struct omap_rng_dev *priv)
+{
+ return omap_rng_read(priv, RNG_STATUS_REG) ? 0 : 1;
+}
+
+static int omap2_rng_init(struct omap_rng_dev *priv)
+{
+ omap_rng_write(priv, RNG_SYSCONFIG_REG, 0x1);
+ return 0;
+}
+
+static void omap2_rng_cleanup(struct omap_rng_dev *priv)
+{
+ omap_rng_write(priv, RNG_SYSCONFIG_REG, 0x0);
+}
+
+static struct omap_rng_pdata omap2_rng_pdata = {
+ .regs = (u16 *)reg_map_omap2,
+ .data_size = OMAP2_RNG_OUTPUT_SIZE,
+ .data_present = omap2_rng_data_present,
+ .init = omap2_rng_init,
+ .cleanup = omap2_rng_cleanup,
+};
+
+#if defined(CONFIG_OF)
+static inline u32 omap4_rng_data_present(struct omap_rng_dev *priv)
+{
+ return omap_rng_read(priv, RNG_STATUS_REG) & RNG_REG_STATUS_RDY;
+}
+
static int omap4_rng_init(struct omap_rng_dev *priv)
{
u32 val;
@@ -221,33 +265,6 @@ static void omap4_rng_cleanup(struct omap_rng_dev *priv)
omap_rng_write(priv, RNG_CONFIG_REG, val);
}
-static int omap2_rng_init(struct omap_rng_dev *priv)
-{
- omap_rng_write(priv, RNG_SYSCONFIG_REG, 0x1);
- return 0;
-}
-
-static void omap2_rng_cleanup(struct omap_rng_dev *priv)
-{
- omap_rng_write(priv, RNG_SYSCONFIG_REG, 0x0);
-}
-
-static int omap_rng_init(struct hwrng *rng)
-{
- struct omap_rng_dev *priv;
-
- priv = (struct omap_rng_dev *)rng->priv;
- return priv->pdata->init(priv);
-}
-
-static void omap_rng_cleanup(struct hwrng *rng)
-{
- struct omap_rng_dev *priv;
-
- priv = (struct omap_rng_dev *)rng->priv;
- priv->pdata->cleanup(priv);
-}
-
static irqreturn_t omap4_rng_irq(int irq, void *dev_id)
{
struct omap_rng_dev *priv = dev_id;
@@ -275,23 +292,6 @@ static irqreturn_t omap4_rng_irq(int irq, void *dev_id)
return IRQ_HANDLED;
}
-static struct hwrng omap_rng_ops = {
- .name = "omap",
- .data_present = omap_rng_data_present,
- .data_read = omap_rng_data_read,
- .init = omap_rng_init,
- .cleanup = omap_rng_cleanup,
-};
-
-static struct omap_rng_pdata omap2_rng_pdata = {
- .regs = (u16 *)reg_map_omap2,
- .data_size = OMAP2_RNG_OUTPUT_SIZE,
- .data_present = omap2_rng_data_present,
- .init = omap2_rng_init,
- .cleanup = omap2_rng_cleanup,
-};
-
-#if defined(CONFIG_OF)
static struct omap_rng_pdata omap4_rng_pdata = {
.regs = (u16 *)reg_map_omap4,
.data_size = OMAP4_RNG_OUTPUT_SIZE,
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH v2 04/14] crypto: omap-aes: Simplify DMA usage by using direct SGs
From: Joel Fernandes @ 2013-08-21 0:54 UTC (permalink / raw)
To: Lokesh Vutla
Cc: Herbert Xu, David S. Miller, Mark Greer, Tony Lindgren,
Santosh Shilimkar, Rajendra Nayak, Linux OMAP List,
Linux ARM Kernel List, Linux Kernel Mailing List,
Linux Crypto Mailing List
In-Reply-To: <521367B4.2020203@ti.com>
On 08/20/2013 07:57 AM, Lokesh Vutla wrote:
> Hi Joel,
>
> On Sunday 18 August 2013 08:12 AM, Joel Fernandes wrote:
>> In early version of this driver, assumptions were made such as DMA layer
>> requires contiguous buffers etc. Due to this, new buffers were allocated,
>> mapped and used for DMA. These assumptions are no longer true and DMAEngine
>> scatter-gather DMA doesn't have such requirements. We simply the DMA operations
>> by directly using the scatter-gather buffers provided by the crypto layer
>> instead of creating our own.
>>
>> Lot of logic that handled DMA'ing only X number of bytes of the total, or as
>> much as fitted into a 3rd party buffer is removed and is no longer required.
>>
>> Also, good performance improvement of atleast ~20% seen with encrypting a
>> buffer size of 8K (1800 ops/sec vs 1400 ops/sec). Improvement will be higher
>> for much larger blocks though such benchmarking is left as an exercise for the
>> reader. Also DMA usage is much more simplified and coherent with rest of the
>> code.
>>
>> Signed-off-by: Joel Fernandes <joelf@ti.com>
>> ---
>> drivers/crypto/omap-aes.c | 147 ++++++++-------------------------------------
>> 1 file changed, 25 insertions(+), 122 deletions(-)
>>
>> diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
>> index e369e6e..64dd5c1 100644
>> --- a/drivers/crypto/omap-aes.c
>> +++ b/drivers/crypto/omap-aes.c
>> @@ -480,22 +480,14 @@ static int sg_copy(struct scatterlist **sg, size_t *offset, void *buf,
>> }
>>
>> static int omap_aes_crypt_dma(struct crypto_tfm *tfm,
>> - struct scatterlist *in_sg, struct scatterlist *out_sg)
>> + struct scatterlist *in_sg, struct scatterlist *out_sg,
>> + int in_sg_len, int out_sg_len)
>> {
>> struct omap_aes_ctx *ctx = crypto_tfm_ctx(tfm);
>> struct omap_aes_dev *dd = ctx->dd;
>> struct dma_async_tx_descriptor *tx_in, *tx_out;
>> struct dma_slave_config cfg;
>> - dma_addr_t dma_addr_in = sg_dma_address(in_sg);
>> - int ret, length = sg_dma_len(in_sg);
>> -
>> - pr_debug("len: %d\n", length);
>> -
>> - dd->dma_size = length;
>> -
>> - if (!(dd->flags & FLAGS_FAST))
>> - dma_sync_single_for_device(dd->dev, dma_addr_in, length,
>> - DMA_TO_DEVICE);
>> + int ret;
> By this change FLAGS_FAST is unsed, it can be cleaned right?
> or Am I missing something?
Yes, FLAGS_FAST would be unused now and can go away. Since it is very trivial
change, I will make this change in the not-immediate future and submit.
Thanks,
-Joel
^ permalink raw reply
* Re: [PATCH] hwrng: reorder OMAP TRNG driver code
From: Lokesh Vutla @ 2013-08-21 5:21 UTC (permalink / raw)
To: Olof Johansson; +Cc: herbert, linux-arm-kernel, linux-crypto, linux-omap
In-Reply-To: <1377022073-28198-1-git-send-email-olof@lixom.net>
Hi Olof,
On Tuesday 20 August 2013 11:37 PM, Olof Johansson wrote:
> The newly added omap4 support in the driver was added without
> consideration for building older configs. When building omap1_defconfig,
> it resulted in:
>
> drivers/char/hw_random/omap-rng.c:190:12: warning: 'omap4_rng_init' defined but not used [-Wunused-function]
> drivers/char/hw_random/omap-rng.c:215:13: warning: 'omap4_rng_cleanup' defined but not used [-Wunused-function]
> drivers/char/hw_random/omap-rng.c:251:20: warning: 'omap4_rng_irq' defined but not used [-Wunused-function]
>
> Move the code around so it is grouped with its operations struct, which
> for the omap4 case means also under the #ifdef CONFIG_OF, where it needs
> to be.
>
Missed testing this. Thanks for the patch.
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Regards,
Lokesh
> Signed-off-by: Olof Johansson <olof@lixom.net>
> Cc: Lokesh Vutla <lokeshvutla@ti.com>
> ---
> drivers/char/hw_random/omap-rng.c | 108 ++++++++++++++++++-------------------
> 1 file changed, 54 insertions(+), 54 deletions(-)
>
> diff --git a/drivers/char/hw_random/omap-rng.c b/drivers/char/hw_random/omap-rng.c
> index f3f7142..9b89ff4 100644
> --- a/drivers/char/hw_random/omap-rng.c
> +++ b/drivers/char/hw_random/omap-rng.c
> @@ -140,16 +140,6 @@ static inline void omap_rng_write(struct omap_rng_dev *priv, u16 reg,
> __raw_writel(val, priv->base + priv->pdata->regs[reg]);
> }
>
> -static inline u32 omap2_rng_data_present(struct omap_rng_dev *priv)
> -{
> - return omap_rng_read(priv, RNG_STATUS_REG) ? 0 : 1;
> -}
> -
> -static inline u32 omap4_rng_data_present(struct omap_rng_dev *priv)
> -{
> - return omap_rng_read(priv, RNG_STATUS_REG) & RNG_REG_STATUS_RDY;
> -}
> -
> static int omap_rng_data_present(struct hwrng *rng, int wait)
> {
> struct omap_rng_dev *priv;
> @@ -187,6 +177,60 @@ static int omap_rng_data_read(struct hwrng *rng, u32 *data)
> return data_size;
> }
>
> +static int omap_rng_init(struct hwrng *rng)
> +{
> + struct omap_rng_dev *priv;
> +
> + priv = (struct omap_rng_dev *)rng->priv;
> + return priv->pdata->init(priv);
> +}
> +
> +static void omap_rng_cleanup(struct hwrng *rng)
> +{
> + struct omap_rng_dev *priv;
> +
> + priv = (struct omap_rng_dev *)rng->priv;
> + priv->pdata->cleanup(priv);
> +}
> +
> +static struct hwrng omap_rng_ops = {
> + .name = "omap",
> + .data_present = omap_rng_data_present,
> + .data_read = omap_rng_data_read,
> + .init = omap_rng_init,
> + .cleanup = omap_rng_cleanup,
> +};
> +
> +static inline u32 omap2_rng_data_present(struct omap_rng_dev *priv)
> +{
> + return omap_rng_read(priv, RNG_STATUS_REG) ? 0 : 1;
> +}
> +
> +static int omap2_rng_init(struct omap_rng_dev *priv)
> +{
> + omap_rng_write(priv, RNG_SYSCONFIG_REG, 0x1);
> + return 0;
> +}
> +
> +static void omap2_rng_cleanup(struct omap_rng_dev *priv)
> +{
> + omap_rng_write(priv, RNG_SYSCONFIG_REG, 0x0);
> +}
> +
> +static struct omap_rng_pdata omap2_rng_pdata = {
> + .regs = (u16 *)reg_map_omap2,
> + .data_size = OMAP2_RNG_OUTPUT_SIZE,
> + .data_present = omap2_rng_data_present,
> + .init = omap2_rng_init,
> + .cleanup = omap2_rng_cleanup,
> +};
> +
> +#if defined(CONFIG_OF)
> +static inline u32 omap4_rng_data_present(struct omap_rng_dev *priv)
> +{
> + return omap_rng_read(priv, RNG_STATUS_REG) & RNG_REG_STATUS_RDY;
> +}
> +
> static int omap4_rng_init(struct omap_rng_dev *priv)
> {
> u32 val;
> @@ -221,33 +265,6 @@ static void omap4_rng_cleanup(struct omap_rng_dev *priv)
> omap_rng_write(priv, RNG_CONFIG_REG, val);
> }
>
> -static int omap2_rng_init(struct omap_rng_dev *priv)
> -{
> - omap_rng_write(priv, RNG_SYSCONFIG_REG, 0x1);
> - return 0;
> -}
> -
> -static void omap2_rng_cleanup(struct omap_rng_dev *priv)
> -{
> - omap_rng_write(priv, RNG_SYSCONFIG_REG, 0x0);
> -}
> -
> -static int omap_rng_init(struct hwrng *rng)
> -{
> - struct omap_rng_dev *priv;
> -
> - priv = (struct omap_rng_dev *)rng->priv;
> - return priv->pdata->init(priv);
> -}
> -
> -static void omap_rng_cleanup(struct hwrng *rng)
> -{
> - struct omap_rng_dev *priv;
> -
> - priv = (struct omap_rng_dev *)rng->priv;
> - priv->pdata->cleanup(priv);
> -}
> -
> static irqreturn_t omap4_rng_irq(int irq, void *dev_id)
> {
> struct omap_rng_dev *priv = dev_id;
> @@ -275,23 +292,6 @@ static irqreturn_t omap4_rng_irq(int irq, void *dev_id)
> return IRQ_HANDLED;
> }
>
> -static struct hwrng omap_rng_ops = {
> - .name = "omap",
> - .data_present = omap_rng_data_present,
> - .data_read = omap_rng_data_read,
> - .init = omap_rng_init,
> - .cleanup = omap_rng_cleanup,
> -};
> -
> -static struct omap_rng_pdata omap2_rng_pdata = {
> - .regs = (u16 *)reg_map_omap2,
> - .data_size = OMAP2_RNG_OUTPUT_SIZE,
> - .data_present = omap2_rng_data_present,
> - .init = omap2_rng_init,
> - .cleanup = omap2_rng_cleanup,
> -};
> -
> -#if defined(CONFIG_OF)
> static struct omap_rng_pdata omap4_rng_pdata = {
> .regs = (u16 *)reg_map_omap4,
> .data_size = OMAP4_RNG_OUTPUT_SIZE,
>
^ permalink raw reply
* Re: [RFC] [PATCH] Fix for a warning - crypto/fcrypt,c
From: Herbert Xu @ 2013-08-21 10:47 UTC (permalink / raw)
To: Jan-Simon Möller; +Cc: David S. Miller, linux-crypto, behanw, pageexec
In-Reply-To: <4092573.JCpLRYcAKP@aragorn.auenland.lan>
On Thu, Aug 15, 2013 at 02:01:50PM +0200, Jan-Simon Möller wrote:
> Hi all,
>
> please merge the attached patch.
>
> Fix for warning:
> linux/crypto/fcrypt.c:143:47: warning: signed shift result (0x598000000)
> requires 36 bits to
> represent, but 'int' only has 32 bits [-Wshift-overflow]
> Z(0xef), Z(0x70), Z(0xcf), Z(0xc2), Z(0x2a), Z(0xb3), Z(0x61),
> Z(0xad),
> ^~~~~~~
> linux/crypto/fcrypt.c:113:29: note: expanded from macro 'Z'
> #define Z(x) cpu_to_be32((x << 27 ) | (x >> 5))
> ^ ~~
> linux/include/uapi/linux/byteorder/little_endian.h:38:53: note: expanded from
> macro
> '__cpu_to_be32'
> #define __cpu_to_be32(x) ((__force __be32)__swab32((x)))
> ^
> linux/include/uapi/linux/swab.h:116:21: note: expanded from macro '__swab32'
> ___constant_swab32(x) : \
> ^
> linux/include/uapi/linux/swab.h:18:12: note: expanded from macro
> '___constant_swab32'
> (((__u32)(x) & (__u32)0x0000ff00UL) << 8) | \
> ^
>
> Solution - make sure we don't exceed the 32 bit range by adding (x & ~(1U <<
> 27))
> = & (0xF7FFFFFF)_16 or & (1111 0111 1111 1111 1111 1111 1111 1111)_2
Your fix makes no sense. To achieve what you want you'd need to lop
off the first 5 bits, not the fifth bit.
However, which compiler is this? This warning seems to be rather
pointless.
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 2/2] crypto/camellia_generic.c: replace commas by semicolons and adjust code alignment
From: Herbert Xu @ 2013-08-21 11:49 UTC (permalink / raw)
To: Julia Lawall; +Cc: kernel-janitors, David S. Miller, linux-crypto, linux-kernel
In-Reply-To: <1376488378-10601-2-git-send-email-Julia.Lawall@lip6.fr>
On Wed, Aug 14, 2013 at 03:52:58PM +0200, Julia Lawall wrote:
> From: Julia Lawall <Julia.Lawall@lip6.fr>
>
> Adjust alignment and replace commas by semicolons in automatically
> generated code.
>
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Both patches applied.
--
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/1] Check for osxsave as well as avx in crypto/xor
From: Herbert Xu @ 2013-08-21 11:50 UTC (permalink / raw)
To: John Haxby; +Cc: "David S. Miller", linux-crypto
In-Reply-To: <1376493798-9668-1-git-send-email-john.haxby@oracle.com>
On Wed, Aug 14, 2013 at 04:23:17PM +0100, John Haxby wrote:
> Hello,
>
> The crypto/xor module omits a check for osxsave. This is a problem on
> sufficiently new hardware but with, for example, a PV guest on a
> sufficiently old version of xeni (eg 3.4). This shows up on Amazon EC2
> under a slightly different guise (see
> http://blog.picloud.com/2013/01/08/when-ec2-hardware-changes-underneath-you/
> or http://tinyurl.com/bezgbhs). In this case, however, "modprobe xor" will
> give something like this:
>
> [11902.030050] xor: automatically using best checksumming function:
> [11902.030746] invalid opcode: 0000 [#1] SMP
> [11902.030752] Modules linked in: xor(+) [...]
> [11902.030771] CPU: 0 PID: 1287 Comm: modprobe Not tainted 3.10.5 #1
> [...]
> [11902.031105] Call Trace:
> [11902.031121] [<ffffffffa0160071>] do_xor_speed+0x71/0xc2 [xor]
> [11902.031213] [<ffffffffa016012d>] calibrate_xor_blocks+0x6b/0xf3e [xor]
> [11902.031217] [<ffffffffa01600c2>] ? do_xor_speed+0xc2/0xc2 [xor]
> [11902.031222] [<ffffffff810020e2>] do_one_initcall+0xe2/0x190
> [11902.031249] [<ffffffff810bf00d>] load_module+0x1b9d/0x2640
>
> Although this is an explicit modprobe, one more serious side effect of
> xor failing like this is that btrfs depends on xor and without it I was
> unable to mount a btrfs filesystem.
>
> The fix is straightforward: add a check for cpu_has_oxsave. This puts xor
> in line with the other crypto modules that use avx.
Patch 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 2/2] crypto: caam - add option for enabling DEBUG mode
From: Herbert Xu @ 2013-08-21 11:50 UTC (permalink / raw)
To: Alex Porosanu; +Cc: linux-crypto, kim.phillips, horia.geanta
In-Reply-To: <1376495806-26226-2-git-send-email-alexandru.porosanu@freescale.com>
On Wed, Aug 14, 2013 at 06:56:46PM +0300, Alex Porosanu wrote:
> This patch adds an option to the Kconfig file for
> SEC which enables the user to see the debug messages
> that are printed inside the SEC driver.
>
> Signed-off-by: Alex Porosanu <alexandru.porosanu@freescale.com>
Both patches applied.
--
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] crypto:nx - fix nx-aes-gcm verification
From: Herbert Xu @ 2013-08-21 11:50 UTC (permalink / raw)
To: jmlatten; +Cc: linuxppc-dev, linux-crypto
In-Reply-To: <520c0215.kHFgBNcJQfAPXpv3%jmlatten@linux.vnet.ibm.com>
On Wed, Aug 14, 2013 at 05:17:57PM -0500, jmlatten@linux.vnet.ibm.com wrote:
> This patch fixes a bug in the nx-aes-gcm implementation.
> Corrected the code so that the authtag is always verified after
> decrypting and not just when there is associated data included.
> Also, corrected the code to retrieve the input authtag from src
> instead of dst.
>
> Reviewed-by: Fionnuala Gunter <fin@linux.vnet.ibm.com>
> Reviewed-by: Marcelo Cerri <mhcerri@linux.vnet.ibm.com>
> Signed-off-by: Joy Latten <jmlatten@linux.vnet.ibm.com>
Patch 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 00/14] crypto: omap-aes: Improve DMA, add PIO mode and support for AM437x
From: Herbert Xu @ 2013-08-21 11:50 UTC (permalink / raw)
To: Joel Fernandes
Cc: David S. Miller, Mark Greer, Tony Lindgren, Santosh Shilimkar,
Rajendra Nayak, Lokesh Vutla, Linux OMAP List,
Linux ARM Kernel List, Linux Kernel Mailing List,
Linux Crypto Mailing List
In-Reply-To: <1376793755-30478-1-git-send-email-joelf@ti.com>
On Sat, Aug 17, 2013 at 09:42:21PM -0500, Joel Fernandes wrote:
> Following patch series rewrites the DMA code to be cleaner and faster. Earlier,
> only a single SG was used for DMA purpose, and the SG-list passed from the
> crypto layer was being copied and DMA'd one entry at a time. This turns out to
> be quite inefficient and lot of code, we replace it with much simpler approach
> that directly passes the SG-list from crypto to the DMA layers for cases where
> possible. For all cases where such a direct passing of SG list is not possible,
> we create a new SG-list and do the copying. This is still better than before, as
> we create an SG list as big as needed and not just 1-element list.
>
> We also add PIO mode support to the driver, and switch to it whenever the DMA
> channel allocation is not available. This also has shown to give good performance
> for small blocks as shown below.
>
> Tests have been performed on AM335x, OMAP4 and AM437x SoCs.
>
> Below is a sample run on AM335x SoC (beaglebone board), showing
> performance improvement (20% for 8K blocks):
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] crypto: tegra-aes - bitwise vs logical and
From: Herbert Xu @ 2013-08-21 11:51 UTC (permalink / raw)
To: Dan Carpenter
Cc: David S. Miller, Stephen Warren, Grant Likely, Rob Herring,
linux-crypto, linux-tegra, devicetree, kernel-janitors
In-Reply-To: <20130820085447.GA20170@elgon.mountain>
On Tue, Aug 20, 2013 at 11:54:48AM +0300, Dan Carpenter wrote:
> The bug here is that:
>
> while (eng_busy & (!icq_empty) & dma_busy)
>
> is never true because it's using bitwise instead of logical ANDs. The
> other bitwise AND conditions work as intended but I changed them as well
> for consistency.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Also applied.
--
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] crypto: sahara - checking the wrong variable
From: Herbert Xu @ 2013-08-21 11:51 UTC (permalink / raw)
To: Dan Carpenter
Cc: David S. Miller, Grant Likely, Rob Herring, linux-crypto,
devicetree, kernel-janitors
In-Reply-To: <20130820085141.GA7469@elgon.mountain>
On Tue, Aug 20, 2013 at 11:51:41AM +0300, Dan Carpenter wrote:
> There is a typo here. "dev->hw_link[]" is an array, not a pointer, so
> the check is nonsense. We should be checking recently allocated
> "dev->hw_link[0]" instead.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Patch applied.
--
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/2] crypto: omap-sham: Misc updates for driver
From: Herbert Xu @ 2013-08-21 11:51 UTC (permalink / raw)
To: Lokesh Vutla; +Cc: linux-crypto, linux-omap, rnayak, nsekhar
In-Reply-To: <1377010955-5605-1-git-send-email-lokeshvutla@ti.com>
On Tue, Aug 20, 2013 at 08:32:33PM +0530, Lokesh Vutla wrote:
> This patch series updates the following for the driver:
> -> Enable polling mode if DMA fails.
> -> Correct the DMA burst size.
>
> Lokesh Vutla (2):
> crypto: omap-sham: Enable Polling mode if DMA fails
> crypto: omap-sham: correct dma burst size
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] hwrng: reorder OMAP TRNG driver code
From: Herbert Xu @ 2013-08-21 11:51 UTC (permalink / raw)
To: Lokesh Vutla; +Cc: Olof Johansson, linux-arm-kernel, linux-crypto, linux-omap
In-Reply-To: <52144E4C.4050405@ti.com>
On Wed, Aug 21, 2013 at 10:51:16AM +0530, Lokesh Vutla wrote:
> Hi Olof,
> On Tuesday 20 August 2013 11:37 PM, Olof Johansson wrote:
> > The newly added omap4 support in the driver was added without
> > consideration for building older configs. When building omap1_defconfig,
> > it resulted in:
> >
> > drivers/char/hw_random/omap-rng.c:190:12: warning: 'omap4_rng_init' defined but not used [-Wunused-function]
> > drivers/char/hw_random/omap-rng.c:215:13: warning: 'omap4_rng_cleanup' defined but not used [-Wunused-function]
> > drivers/char/hw_random/omap-rng.c:251:20: warning: 'omap4_rng_irq' defined but not used [-Wunused-function]
> >
> > Move the code around so it is grouped with its operations struct, which
> > for the omap4 case means also under the #ifdef CONFIG_OF, where it needs
> > to be.
> >
> Missed testing this. Thanks for the patch.
> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Patch 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: [RFC] [PATCH] Fix for a warning - crypto/fcrypt,c
From: PaX Team @ 2013-08-21 15:39 UTC (permalink / raw)
To: Jan-Simon Möller, Herbert Xu; +Cc: David S. Miller, linux-crypto, behanw
In-Reply-To: <20130821104715.GA22975@gondor.apana.org.au>
On 21 Aug 2013 at 20:47, Herbert Xu wrote:
> On Thu, Aug 15, 2013 at 02:01:50PM +0200, Jan-Simon Möller wrote:
> > Solution - make sure we don't exceed the 32 bit range by adding (x & ~(1U <<
> > 27))
> > = & (0xF7FFFFFF)_16 or & (1111 0111 1111 1111 1111 1111 1111 1111)_2
>
> Your fix makes no sense. To achieve what you want you'd need to lop
> off the first 5 bits, not the fifth bit.
oops, the bitmask expression wanted to be (1U << 27) - 1) instead.
another approach would be to simply cast the macro argument to __be32.
> However, which compiler is this? This warning seems to be rather
> pointless.
it's clang and this warning is about an undefined behaviour because
the hexadecimal constants passed to this macro are treated as signed
ints and for some of the constants the result of the shift cannot be
represented as a signed int.
^ permalink raw reply
* Re: [RFC] [PATCH] Fix for a warning - crypto/fcrypt,c
From: Jan-Simon Möller @ 2013-08-21 20:42 UTC (permalink / raw)
To: Herbert Xu, linux-crypto; +Cc: behanw, pageexec
In-Reply-To: <4092573.JCpLRYcAKP@aragorn.auenland.lan>
Should I resend a fixed version with
(1U << 27) - 1) instead ?
Best,
JS
On Thursday 15 August 2013 14:01:50 Jan-Simon Möller wrote:
> Hi all,
>
> please merge the attached patch.
>
> Fix for warning:
> linux/crypto/fcrypt.c:143:47: warning: signed shift result (0x598000000)
> requires 36 bits to
> represent, but 'int' only has 32 bits [-Wshift-overflow]
> Z(0xef), Z(0x70), Z(0xcf), Z(0xc2), Z(0x2a), Z(0xb3), Z(0x61),
> Z(0xad),
> ^~~~~~~
> linux/crypto/fcrypt.c:113:29: note: expanded from macro 'Z'
> #define Z(x) cpu_to_be32((x << 27 ) | (x >> 5))
> ^ ~~
> linux/include/uapi/linux/byteorder/little_endian.h:38:53: note: expanded
> from macro
> '__cpu_to_be32'
> #define __cpu_to_be32(x) ((__force __be32)__swab32((x)))
> ^
> linux/include/uapi/linux/swab.h:116:21: note: expanded from macro '__swab32'
> ___constant_swab32(x) : \
> ^
> linux/include/uapi/linux/swab.h:18:12: note: expanded from macro
> '___constant_swab32'
> (((__u32)(x) & (__u32)0x0000ff00UL) << 8) | \
> ^
>
> Solution - make sure we don't exceed the 32 bit range by adding (x & ~(1U <<
> 27))
> = & (0xF7FFFFFF)_16 or & (1111 0111 1111 1111 1111 1111 1111 1111)_2
>
>
> Author: PaX Team <pageexec at freemail.hu>
> ML-Post:
> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120507/142707
> .html URL: http://llvm.linuxfoundation.org
>
> Merge: Jan-Simon Möller <dl9pf at gmx.de>
>
>
>
> Best,
^ permalink raw reply
* Re: [PATCH] kernel/padata.c: always check the return value of __padata_remove_cpu() and __padata_add_cpu()
From: Steffen Klassert @ 2013-08-22 5:11 UTC (permalink / raw)
To: Chen Gang; +Cc: linux-crypto, linux-kernel@vger.kernel.org
In-Reply-To: <5212E61F.7010602@asianux.com>
On Tue, Aug 20, 2013 at 11:44:31AM +0800, Chen Gang wrote:
>
> If this patch is correct, better to let CPU_ONLINE and CPU_DOWN_FAILED
> share the same code.
>
> And do we need a comment "/* fall through */" between CPU_UP_CANCELED
> and CPU_DOWN_FAILED (or it is another bug, need a 'break' statement) ?
>
> At last, also better to let CPU_DOWN_PREPARE and CPU_UP_CANCELED share
> the same code (if need a 'break'), or share the most of code (if "fall
> through").
>
CPU_ONLINE and CPU_DOWN_FAILED can share the code. Same is true for
CPU_DOWN_PREPARE and CPU_UP_CANCELED.
Thanks!
^ 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