2010-03-17 13:12:49

by Dmitry Kasatkin

[permalink] [raw]
Subject: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

Earlier kernel contained omap sha1 and md5 driver, which was not maintained,
was not ported to new crypto APIs and removed from the source tree.

This driver implements async and sync crypto API.

It still contains pr_debug() for debugging purpose.
Will be remove for integration.

Dmitry Kasatkin (2):
sec: omap sha1 & md5 driver
sec: Makefile/Kconfig update for omap sha1 md5 driver

drivers/crypto/Kconfig | 9 +
drivers/crypto/Makefile | 2 +
drivers/crypto/omap-sha1-md5.c | 1449 ++++++++++++++++++++++++++++++++++++++++
3 files changed, 1460 insertions(+), 0 deletions(-)
create mode 100644 drivers/crypto/omap-sha1-md5.c



2010-03-17 13:18:18

by Dmitry Kasatkin

[permalink] [raw]
Subject: [PATCH 1/2] sec: omap sha1 & md5 driver

Earlier kernel contained omap sha1 and md5 driver, which was not maintained,
was not ported to new crypto APIs and removed from the source tree.

This driver implements async and sync crypto API.

Signed-off-by: Dmitry Kasatkin <[email protected]>
---
drivers/crypto/omap-sha1-md5.c | 1449 ++++++++++++++++++++++++++++++++++++++++
1 files changed, 1449 insertions(+), 0 deletions(-)
create mode 100644 drivers/crypto/omap-sha1-md5.c

diff --git a/drivers/crypto/omap-sha1-md5.c b/drivers/crypto/omap-sha1-md5.c
new file mode 100644
index 0000000..c57c6de
--- /dev/null
+++ b/drivers/crypto/omap-sha1-md5.c
@@ -0,0 +1,1449 @@
+/*
+ * Cryptographic API.
+ *
+ * Support for OMAP SHA1/MD5 HW acceleration.
+ *
+ * Copyright (c) 2007 Instituto Nokia de Tecnologia - INdT
+ * Authors: David Cohen <[email protected]>
+ * Dmitry Kasatkin <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ *
+ * This driver is based on padlock-sha.c driver.
+ */
+
+#define pr_fmt(fmt) "%s: " fmt, __func__
+
+#include <linux/version.h>
+#include <linux/err.h>
+#include <linux/device.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/errno.h>
+#include <linux/cryptohash.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/clk.h>
+#include <linux/irq.h>
+#include <linux/platform_device.h>
+#include <linux/scatterlist.h>
+#include <linux/dma-mapping.h>
+#include <linux/delay.h>
+#include <linux/crypto.h>
+#include <crypto/scatterwalk.h>
+#include <crypto/algapi.h>
+#include <crypto/sha.h>
+#include <crypto/hash.h>
+#include <crypto/internal/hash.h>
+
+#include <plat/cpu.h>
+#include <plat/dma.h>
+#include <mach/irqs.h>
+#include <mach/io.h>
+
+/* OMAP3 SHAM2 module */
+#define OMAP34XX_SEC_SHA1MD5_BASE (L4_34XX_BASE + 0xC3000)
+
+#define SHA_REG_DIGEST(x) (0x00 + ((x) * 0x04))
+#define SHA_REG_DIN(x) (0x1C + ((x) * 0x04))
+
+#define SHA1_MD5_BLOCK_SIZE SHA1_BLOCK_SIZE
+#define MD5_DIGEST_SIZE 16
+
+#define SHA_REG_DIGCNT 0x14
+
+#define SHA_REG_CTRL 0x18
+#define SHA_REG_CTRL_LENGTH (0xFFFFFFFF << 5)
+#define SHA_REG_CTRL_CLOSE_HASH (1 << 4)
+#define SHA_REG_CTRL_ALGO_CONST (1 << 3)
+#define SHA_REG_CTRL_ALGO (1 << 2)
+#define SHA_REG_CTRL_INPUT_READY (1 << 1)
+#define SHA_REG_CTRL_OUTPUT_READY (1 << 0)
+
+#define SHA_REG_REV 0x5C
+#define SHA_REG_REV_MAJOR 0xF0
+#define SHA_REG_REV_MINOR 0x0F
+
+#define SHA_REG_MASK 0x60
+#define SHA_REG_MASK_DMA_EN (1 << 3)
+#define SHA_REG_MASK_IT_EN (1 << 2)
+#define SHA_REG_MASK_SOFTRESET (1 << 1)
+#define SHA_REG_AUTOIDLE (1 << 0)
+
+#define SHA_REG_SYSSTATUS 0x64
+#define SHA_REG_SYSSTATUS_RESETDONE (1 << 0)
+
+#define DRIVER_NAME "omap-sha1-md5"
+
+#ifdef CONFIG_ARCH_OMAP24XX
+#define SHA1_MD5_ICLK "sha_ick"
+#endif
+#ifdef CONFIG_ARCH_OMAP34XX
+#define SHA1_MD5_ICLK "sha12_ick"
+#endif
+
+#define DEFAULT_TIMEOUT_INTERVAL HZ
+
+struct omap_sha1_md5_desc {
+ /* should be last one to have desc area for fallback*/
+ struct shash_desc fallback;
+};
+
+#define FLAGS_UPDATE 0x0001
+#define FLAGS_FINUP 0x0002
+#define FLAGS_FINAL 0x0004
+#define FLAGS_MAY_SLEEP 0x0008
+#define FLAGS_BYPASS_INIT 0x0010
+#define FLAGS_BYPASS 0x0030 /* it's a mask */
+#define FLAGS_FAST 0x0040
+#define FLAGS_SHA1 0x0080
+#define FLAGS_INPROGRESS 0x0100
+#define FLAGS_DMA_ACTIVE 0x0200
+#define FLAGS_READY 0x0400
+#define FLAGS_CLEAN 0x0800
+#define FLAGS_DMA 0x1000
+
+struct omap_sha1_md5_ctx {
+ unsigned long flags;
+ int digsize;
+ size_t bufcnt;
+ size_t digcnt;
+ size_t dma_size;
+ u8 *buffer;
+ size_t buffer_size;
+
+ /* shash stuff */
+ struct crypto_shash *shash_fb;
+ u8 *data;
+
+ /* ahash stuff */
+ struct crypto_ahash *ahash_fb;
+ struct ahash_request *req;
+
+ /* ahash walk state */
+ struct scatterlist *sg;
+ unsigned int offset; /* offset in current sg */
+ unsigned int length; /* length left in current sg */
+ unsigned int total; /* total request */
+};
+
+struct omap_sha1_md5_dev {
+ unsigned long phys_base;
+ struct device *dev;
+ void __iomem *io_base;
+ int irq;
+ struct clk *iclk;
+ struct omap_sha1_md5_ctx *hw_ctx;
+ wait_queue_head_t wq;
+ spinlock_t lock;
+ int dma;
+ dma_addr_t dma_addr;
+ dma_addr_t buffer_addr;
+ int dma_lch;
+ struct completion dma_wait;
+ struct tasklet_struct done_task;
+};
+
+/* device data */
+static struct omap_sha1_md5_dev *dd;
+
+static int omap_sha1_md5_update_dma_slow(struct omap_sha1_md5_ctx *ctx);
+static int omap_sha1_md5_update_dma_stop(struct omap_sha1_md5_ctx *ctx);
+static void omap_sha1_md5_hw_cleanup(struct omap_sha1_md5_ctx *ctx, u8 *out);
+
+static inline u32 omap_sha1_md5_read(struct omap_sha1_md5_dev *dd, u32 offset)
+{
+ return __raw_readl(dd->io_base + offset);
+}
+
+static inline void omap_sha1_md5_write(struct omap_sha1_md5_dev *dd,
+ u32 offset, u32 value)
+{
+ __raw_writel(value, dd->io_base + offset);
+}
+
+static void omap_sha1_md5_write_mask(struct omap_sha1_md5_dev *dd, u32 address,
+ u32 value, u32 mask)
+{
+ u32 val;
+
+ val = omap_sha1_md5_read(dd, address);
+ val &= ~mask;
+ val |= value;
+ omap_sha1_md5_write(dd, address, val);
+}
+
+static int omap_sha1_md5_wait(struct omap_sha1_md5_dev *dd, u32 offset, u32 bit)
+{
+ unsigned long timeout = jiffies + DEFAULT_TIMEOUT_INTERVAL;
+
+ while (!(omap_sha1_md5_read(dd, offset) & bit)) {
+ if (time_is_before_jiffies(timeout))
+ return -ETIMEDOUT;
+ }
+
+ return 0;
+}
+
+static void omap_sha1_md5_copy_hash(struct omap_sha1_md5_ctx *ctx, u32 *hash)
+{
+ int i;
+
+ if (ctx->flags & FLAGS_SHA1) {
+ /* SHA1 results are in big endian */
+ for (i = 0; i < SHA1_DIGEST_SIZE / sizeof(u32); i++)
+ hash[i] = be32_to_cpu(
+ omap_sha1_md5_read(dd, SHA_REG_DIGEST(i)));
+ } else {
+ /* MD5 results are in little endian */
+ for (i = 0; i < MD5_DIGEST_SIZE / sizeof(u32); i++)
+ hash[i] = le32_to_cpu(
+ omap_sha1_md5_read(dd, SHA_REG_DIGEST(i)));
+ }
+}
+
+static int omap_sha1_md5_wait_for_output_ready(struct omap_sha1_md5_ctx *ctx)
+{
+ int err;
+
+ pr_debug("enter\n");
+
+ if (ctx->flags & FLAGS_READY)
+ return 0;
+
+ if (ctx->flags & FLAGS_DMA) {
+ unsigned long timeout;
+ if (!(ctx->flags & FLAGS_MAY_SLEEP))
+ return -EINPROGRESS;
+ timeout = wait_event_interruptible_timeout(dd->wq,
+ (ctx->flags & FLAGS_READY),
+ DEFAULT_TIMEOUT_INTERVAL);
+ err = timeout > 0 ? 0 : -ETIMEDOUT;
+ } else {
+ err = omap_sha1_md5_wait(dd, SHA_REG_CTRL,
+ SHA_REG_CTRL_OUTPUT_READY);
+ }
+ pr_debug("exit: %d\n", (omap_sha1_md5_read(dd, SHA_REG_CTRL)
+ & SHA_REG_CTRL_OUTPUT_READY) != 0);
+
+ return err;
+}
+
+static irqreturn_t omap_sha1_md5_irq(int irq, void *dev_id)
+{
+ struct omap_sha1_md5_ctx *ctx = dd->hw_ctx;
+
+ pr_debug("enter\n");
+ pr_debug("ready: %d\n", (omap_sha1_md5_read(dd, SHA_REG_CTRL) &
+ SHA_REG_CTRL_OUTPUT_READY) != 0);
+
+ if (!ctx) {
+ dev_err(dd->dev, "unknown interrupt.\n");
+ return IRQ_HANDLED;
+ }
+
+ if (unlikely(ctx->flags & FLAGS_FINAL))
+ /* final -> allow device to go to power-saving mode */
+ omap_sha1_md5_write_mask(dd, SHA_REG_CTRL, 0,
+ SHA_REG_CTRL_LENGTH);
+
+ omap_sha1_md5_write_mask(dd, SHA_REG_CTRL, SHA_REG_CTRL_OUTPUT_READY,
+ SHA_REG_CTRL_OUTPUT_READY);
+
+ if (likely(!(ctx->flags & FLAGS_FINAL)))
+ return IRQ_HANDLED;
+
+ ctx->flags |= FLAGS_READY;
+
+ pr_debug("DIGEST READY\n");
+
+ /* hash is done */
+ if (ctx->flags & FLAGS_MAY_SLEEP)
+ wake_up_interruptible(&dd->wq);
+ else
+ tasklet_schedule(&dd->done_task);
+
+ return IRQ_HANDLED;
+}
+
+static int omap_sha1_md5_wait_for_dma(struct omap_sha1_md5_ctx *ctx)
+{
+ int err = 0;
+
+ pr_debug("enter\n");
+ if ((ctx->flags & FLAGS_INPROGRESS) && !(ctx->flags & FLAGS_FINUP)) {
+ unsigned long timeout;
+ if (!(ctx->flags & FLAGS_MAY_SLEEP))
+ return -EINPROGRESS;
+ pr_debug("do wait\n");
+ timeout = wait_for_completion_timeout(&dd->dma_wait,
+ DEFAULT_TIMEOUT_INTERVAL);
+ err = timeout > 0 ? 0 : -ETIMEDOUT;
+ }
+ pr_debug("exit\n");
+
+ return err;
+}
+
+static void omap_sha1_md5_done(unsigned long data)
+{
+ struct omap_sha1_md5_ctx *ctx = dd->hw_ctx;
+
+ pr_debug("enter\n");
+
+ if (ctx->flags & FLAGS_FINAL)
+ omap_sha1_md5_hw_cleanup(ctx, ctx->req->result);
+
+ if (ctx->req && ctx->req->base.complete)
+ ctx->req->base.complete(&ctx->req->base, 0);
+
+ pr_debug("exit\n");
+}
+
+static void omap_sha1_md5_dma_callback(int lch, u16 ch_status, void *data)
+{
+ struct omap_sha1_md5_ctx *ctx = dd->hw_ctx;
+
+ pr_debug("enter\n");
+
+ ctx->flags &= ~FLAGS_DMA_ACTIVE;
+
+ omap_sha1_md5_update_dma_stop(ctx);
+ omap_sha1_md5_update_dma_slow(ctx);
+
+ if (!(ctx->flags & FLAGS_DMA_ACTIVE)) {
+ ctx->flags &= ~FLAGS_INPROGRESS;
+ if (!(ctx->flags & FLAGS_FINAL)) {
+ /* irq handler will complete the the hash */
+ if (ctx->flags & FLAGS_MAY_SLEEP)
+ complete(&dd->dma_wait);
+ else
+ tasklet_schedule(&dd->done_task);
+ }
+ }
+
+ pr_debug("exit\n");
+}
+
+static int omap_sha1_md5_hw_init(struct omap_sha1_md5_ctx *ctx, int use_dma)
+{
+ int err;
+
+ pr_debug("enter\n");
+
+ /* in the case of error clk_disable() is in final() */
+ clk_enable(dd->iclk);
+
+ if (use_dma) {
+ err = omap_request_dma(dd->dma, "OMAP-SHA1-MD5",
+ omap_sha1_md5_dma_callback, dd, &dd->dma_lch);
+ if (err) {
+ dev_err(dd->dev, "Unable to request DMA channel\n");
+ return err;
+ }
+ omap_set_dma_dest_params(dd->dma_lch, 0,
+ OMAP_DMA_AMODE_CONSTANT,
+ dd->phys_base + SHA_REG_DIN(0), 0, 16);
+
+ omap_set_dma_dest_burst_mode(dd->dma_lch,
+ OMAP_DMA_DATA_BURST_16);
+
+ ctx->flags |= FLAGS_DMA;
+ }
+
+ omap_sha1_md5_write_mask(dd, SHA_REG_MASK, SHA_REG_MASK_SOFTRESET,
+ SHA_REG_MASK_SOFTRESET);
+
+ if (omap_sha1_md5_wait(dd, SHA_REG_SYSSTATUS,
+ SHA_REG_SYSSTATUS_RESETDONE))
+ return -ETIMEDOUT;
+
+ /* we use irq handler with dma */
+ omap_sha1_md5_write_mask(dd, SHA_REG_MASK,
+ (dd->dma_lch >= 0 ? SHA_REG_MASK_IT_EN : 0) |
+ (dd->dma_lch >= 0 ? SHA_REG_MASK_DMA_EN : 0),
+ SHA_REG_MASK_DMA_EN | SHA_REG_MASK_IT_EN);
+
+ return 0;
+}
+
+static void omap_sha1_md5_write_ctrl(struct omap_sha1_md5_ctx *ctx,
+ size_t length, int final)
+{
+ u32 val = length << 5, mask;
+
+ /* Setting ALGO_CONST only for the first iteration
+ * and CLOSE_HASH only for the last one. */
+
+ if (ctx->flags & FLAGS_SHA1)
+ val |= SHA_REG_CTRL_ALGO;
+ if (!ctx->digcnt)
+ val |= SHA_REG_CTRL_ALGO_CONST;
+ if (final)
+ val |= SHA_REG_CTRL_CLOSE_HASH;
+
+ mask = SHA_REG_CTRL_ALGO_CONST | SHA_REG_CTRL_CLOSE_HASH |
+ SHA_REG_CTRL_ALGO | SHA_REG_CTRL_LENGTH;
+
+ omap_sha1_md5_write_mask(dd, SHA_REG_CTRL, val, mask);
+}
+
+static int omap_sha1_md5_xmit_cpu(struct omap_sha1_md5_ctx *ctx,
+ const u8 *buf, size_t length, int final)
+{
+ int err, count, len32;
+ const u32 *buffer = (const u32 *)buf;
+
+ pr_debug("digcnt: %d, length: %d, final: %d\n",
+ ctx->digcnt, length, final);
+
+ if (likely(ctx->digcnt)) {
+ omap_sha1_md5_write(dd, SHA_REG_DIGCNT, ctx->digcnt);
+ } else {
+ err = omap_sha1_md5_hw_init(ctx, 0);
+ if (err)
+ return err;
+ }
+
+ omap_sha1_md5_write_ctrl(ctx, length, final);
+
+ ctx->digcnt += length;
+ if (omap_sha1_md5_wait(dd, SHA_REG_CTRL, SHA_REG_CTRL_INPUT_READY))
+ return -ETIMEDOUT;
+
+ if (final)
+ ctx->flags |= FLAGS_FINAL; /* catch last interrupt */
+
+ len32 = DIV_ROUND_UP(length, sizeof(u32));
+
+ for (count = 0; count < len32; count++)
+ omap_sha1_md5_write(dd, SHA_REG_DIN(count), buffer[count]);
+
+ return 0;
+}
+
+static int omap_sha1_md5_xmit_dma(struct omap_sha1_md5_ctx *ctx,
+ dma_addr_t dma_addr,
+ size_t length, int final)
+{
+ int err, len32;
+
+ pr_debug("total: %u, digcnt: %d, length: %d, final: %d\n",
+ ctx->total, ctx->digcnt, length, final);
+
+ if (likely(ctx->digcnt)) {
+ omap_sha1_md5_write(dd, SHA_REG_DIGCNT, ctx->digcnt);
+ } else {
+ err = omap_sha1_md5_hw_init(ctx, 1);
+ if (err)
+ return err;
+ }
+
+ /* flush cache entries related to our page */
+ if (dma_addr == dd->buffer_addr)
+ dma_sync_single_for_device(dd->dev, dma_addr, length,
+ DMA_TO_DEVICE);
+
+ len32 = DIV_ROUND_UP(length, sizeof(u32));
+
+ omap_set_dma_transfer_params(dd->dma_lch, OMAP_DMA_DATA_TYPE_S32, len32,
+ 1, OMAP_DMA_SYNC_PACKET, dd->dma, OMAP_DMA_DST_SYNC);
+
+ omap_set_dma_src_params(dd->dma_lch, 0, OMAP_DMA_AMODE_POST_INC,
+ dma_addr, 0, 0);
+
+ omap_sha1_md5_write_ctrl(ctx, length, final);
+
+ ctx->digcnt += length;
+
+ if (final)
+ ctx->flags |= FLAGS_FINAL; /* catch last interrupt */
+
+ ctx->flags |= FLAGS_INPROGRESS | FLAGS_DMA_ACTIVE;
+
+ omap_start_dma(dd->dma_lch);
+
+ return 0;
+}
+
+static void omap_sha1_md5_append_cpu(struct omap_sha1_md5_ctx *ctx,
+ const u8 *data, size_t length)
+{
+ memcpy(&ctx->buffer[ctx->bufcnt], data, length);
+ ctx->bufcnt += length;
+}
+
+static size_t omap_sha1_md5_append_buffer(struct omap_sha1_md5_ctx *ctx,
+ const u8 *data, size_t length)
+{
+ size_t count = min(length, ctx->buffer_size - ctx->bufcnt);
+
+ count = min(count, ctx->total);
+ if (count <= 0)
+ return 0;
+ memcpy(ctx->buffer + ctx->bufcnt, data, count);
+ ctx->bufcnt += count;
+ return count;
+}
+
+static size_t omap_sha1_md5_append_sg(struct omap_sha1_md5_ctx *ctx)
+{
+ size_t count;
+
+ while (ctx->sg) {
+ count = omap_sha1_md5_append_buffer(ctx,
+ sg_virt(ctx->sg) + ctx->offset, ctx->length);
+ if (!count)
+ break;
+ ctx->length -= count;
+ ctx->offset += count;
+ ctx->total -= count;
+ if (ctx->length == 0) {
+ ctx->sg = sg_next(ctx->sg);
+ if (ctx->sg) {
+ ctx->offset = 0;
+ ctx->length = ctx->sg->length;
+ } else {
+ ctx->total = 0;
+ }
+ }
+ }
+ return 0;
+}
+
+static int omap_sha1_md5_update_cpu(struct omap_sha1_md5_ctx *ctx,
+ const u8 *data, size_t length)
+{
+ unsigned int count;
+ int err;
+
+ pr_debug("enter\n");
+
+ if (ctx->bufcnt) {
+ count = min(length, SHA1_MD5_BLOCK_SIZE - ctx->bufcnt);
+ omap_sha1_md5_append_cpu(ctx, data, count);
+ data += count;
+ length -= count;
+ if (!length)
+ return 0;
+ ctx->bufcnt = 0;
+ err = omap_sha1_md5_xmit_cpu(ctx, ctx->buffer,
+ SHA1_MD5_BLOCK_SIZE, 0);
+ if (err)
+ return err;
+ }
+ /* We need to save the last buffer <= 64 to digest it with
+ * CLOSE_HASH = 1 */
+ while (length > SHA1_MD5_BLOCK_SIZE) {
+ err = omap_sha1_md5_xmit_cpu(ctx, data, SHA1_MD5_BLOCK_SIZE, 0);
+ if (err)
+ return err;
+ length -= SHA1_MD5_BLOCK_SIZE;
+ data += SHA1_MD5_BLOCK_SIZE;
+ }
+ omap_sha1_md5_append_cpu(ctx, data, length);
+
+ return 0;
+}
+
+static int omap_sha1_md5_update_dma_slow(struct omap_sha1_md5_ctx *ctx)
+{
+ unsigned int final;
+ size_t count;
+
+ pr_debug("enter, total: %d\n", ctx->total);
+
+ if (!ctx->total) {
+ pr_debug("no data\n");
+ return 0;
+ }
+
+ omap_sha1_md5_append_sg(ctx);
+
+ final = (ctx->flags & FLAGS_FINUP) && !ctx->total;
+
+ pr_debug("bufcnt: %u, digcnt: %d, final: %d\n",
+ ctx->bufcnt, ctx->digcnt, final);
+
+ if (final || (ctx->bufcnt == ctx->buffer_size && ctx->total)) {
+ count = ctx->bufcnt;
+ ctx->bufcnt = 0;
+ return omap_sha1_md5_xmit_dma(ctx, dd->buffer_addr, count,
+ final);
+ }
+
+ return 0;
+}
+
+static int omap_sha1_md5_update_dma_stop(struct omap_sha1_md5_ctx *ctx)
+{
+ pr_debug("enter\n");
+ omap_stop_dma(dd->dma_lch);
+ if (ctx->flags & FLAGS_FAST) {
+ if (dd->dma_addr) {
+ dma_unmap_single(dd->dev, dd->dma_addr, ctx->dma_size,
+ DMA_TO_DEVICE);
+ dd->dma_addr = 0;
+ } else {
+ dma_unmap_sg(dd->dev, ctx->sg, 1, DMA_TO_DEVICE);
+ }
+ }
+
+ return 0;
+}
+
+static int omap_sha1_md5_init(struct omap_sha1_md5_ctx *ctx)
+{
+ unsigned long flags;
+
+ pr_debug("enter, digest size: %d\n", ctx->digsize);
+
+ spin_lock_irqsave(&dd->lock, flags);
+ if (unlikely(dd->hw_ctx)) {
+ spin_unlock_irqrestore(&dd->lock, flags);
+ ctx->flags |= FLAGS_BYPASS;
+ return 0;
+ }
+ dd->hw_ctx = ctx;
+ spin_unlock_irqrestore(&dd->lock, flags);
+
+ /* clean except may sleep */
+ ctx->flags &= FLAGS_MAY_SLEEP;
+
+ if (ctx->digsize == SHA1_DIGEST_SIZE)
+ ctx->flags |= FLAGS_SHA1;
+
+ ctx->bufcnt = 0;
+ ctx->digcnt = 0;
+
+ dd->dma_lch = -1;
+
+
+ ctx->buffer = (void *)__get_free_page((ctx->flags & FLAGS_MAY_SLEEP) ?
+ GFP_KERNEL : GFP_ATOMIC);
+ if (!ctx->buffer)
+ return -ENOMEM;
+
+ ctx->buffer_size = PAGE_SIZE;
+ dd->buffer_addr = dma_map_single(dd->dev, ctx->buffer, ctx->buffer_size,
+ DMA_TO_DEVICE);
+ if (dma_mapping_error(dd->dev, dd->buffer_addr)) {
+ dev_err(dd->dev, "dma %u bytes error\n", ctx->buffer_size);
+ free_page((unsigned long)ctx->buffer);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int omap_sha1_md5_final(struct omap_sha1_md5_ctx *ctx)
+{
+ int err = 0, use_dma = !!ctx->req;
+
+ pr_debug("enter\n");
+
+ if (ctx->bufcnt) {
+ /* DMA is overhead if only data is <=64b */
+ if (ctx->bufcnt <= 64)
+ /* still use dma if it has been used already */
+ use_dma = dd->dma_lch >= 0;
+ if (use_dma)
+ err = omap_sha1_md5_xmit_dma(ctx, dd->buffer_addr,
+ ctx->bufcnt, 1);
+ else
+ err = omap_sha1_md5_xmit_cpu(ctx, ctx->buffer,
+ ctx->bufcnt, 1);
+ }
+
+ if (err)
+ return err;
+
+ err = omap_sha1_md5_wait_for_output_ready(ctx);
+
+ pr_debug("exit\n");
+
+ return err;
+}
+
+static void omap_sha1_md5_hw_cleanup(struct omap_sha1_md5_ctx *ctx, u8 *out)
+{
+ unsigned long flags;
+
+ pr_debug("enter\n");
+
+ if (ctx->flags & FLAGS_BYPASS)
+ goto exit;
+
+ spin_lock_irqsave(&dd->lock, flags);
+ if (ctx->flags & FLAGS_CLEAN) {
+ spin_unlock_irqrestore(&dd->lock, flags);
+ pr_debug("exit: already clean\n");
+ return;
+ }
+ ctx->flags |= FLAGS_CLEAN;
+ spin_unlock_irqrestore(&dd->lock, flags);
+
+ if (dd->dma_lch >= 0) {
+ /* We can free the channels */
+ omap_free_dma(dd->dma_lch);
+ dd->dma_lch = -1;
+ }
+
+ omap_sha1_md5_copy_hash(ctx, (u32 *)out);
+ clk_disable(dd->iclk);
+
+ if (dd->buffer_addr)
+ dma_unmap_single(dd->dev, dd->buffer_addr, ctx->buffer_size,
+ DMA_TO_DEVICE);
+ if (ctx->buffer) {
+ free_page((unsigned long)ctx->buffer);
+ ctx->buffer = NULL;
+ }
+
+exit:
+ if (dd->hw_ctx == ctx)
+ dd->hw_ctx = NULL;
+ pr_debug("exit\n");
+}
+
+
+/* ******************** SHASH ********************************************* */
+
+static int omap_shash_update_bypass(struct shash_desc *desc,
+ const u8 *data,
+ size_t length)
+{
+ struct omap_sha1_md5_ctx *ctx = crypto_shash_ctx(desc->tfm);
+ struct omap_sha1_md5_desc *_ctx = shash_desc_ctx(desc);
+
+ pr_debug("length: %d\n", length);
+
+ if (ctx->flags & FLAGS_BYPASS_INIT) {
+ int err = crypto_shash_init(&_ctx->fallback);
+ pr_debug("switching to bypass, err: %d\n", err);
+ ctx->flags &= ~FLAGS_BYPASS_INIT;
+ if (err)
+ return err;
+ }
+
+ if (length)
+ return crypto_shash_update(&_ctx->fallback, data, length);
+
+ return 0;
+}
+
+static int omap_shash_init(struct shash_desc *desc)
+{
+ struct omap_sha1_md5_ctx *ctx = crypto_shash_ctx(desc->tfm);
+ struct omap_sha1_md5_desc *_ctx = shash_desc_ctx(desc);
+ int err;
+
+ pr_debug("enter\n");
+
+ _ctx->fallback.tfm = ctx->shash_fb;
+ _ctx->fallback.flags = desc->flags & CRYPTO_TFM_REQ_MAY_SLEEP;
+
+ ctx->digsize = crypto_shash_digestsize(desc->tfm);
+
+ if (desc->flags & CRYPTO_TFM_REQ_MAY_SLEEP)
+ ctx->flags |= FLAGS_MAY_SLEEP;
+
+ err = omap_sha1_md5_init(ctx);
+
+ pr_debug("exit\n");
+
+ return err;
+}
+
+static int omap_shash_update(struct shash_desc *desc, const u8 *data,
+ size_t length)
+{
+ struct omap_sha1_md5_ctx *ctx = crypto_shash_ctx(desc->tfm);
+
+ pr_debug("length: %d, bypass: %d\n", length,
+ (ctx->flags & FLAGS_BYPASS) != 0);
+
+ if (!length)
+ return 0;
+
+ if (ctx->flags & FLAGS_BYPASS)
+ return omap_shash_update_bypass(desc, data, length);
+
+ if ((ctx->flags & FLAGS_FINUP) &&
+ ((ctx->digcnt + ctx->bufcnt + length) < 9)) {
+ /* OMAP HW accel works only with buffers >= 9 */
+ /* will switch to bypass in final() */
+ omap_sha1_md5_append_cpu(ctx, data, length);
+ return 0;
+ }
+
+ return omap_sha1_md5_update_cpu(ctx, data, length);
+}
+
+static int omap_shash_final(struct shash_desc *desc, u8 *out)
+{
+ struct omap_sha1_md5_ctx *ctx = crypto_shash_ctx(desc->tfm);
+ struct omap_sha1_md5_desc *_ctx = shash_desc_ctx(desc);
+ int err = 0;
+
+ pr_debug("enter\n");
+
+ ctx->flags |= FLAGS_FINUP;
+
+ /* OMAP HW accel works only with buffers >= 9 */
+ if ((ctx->flags & FLAGS_BYPASS_INIT) ||
+ ((ctx->digcnt + ctx->bufcnt) < 9 && !(ctx->flags & FLAGS_BYPASS))) {
+ ctx->flags |= FLAGS_BYPASS;
+ err = omap_shash_update_bypass(desc, ctx->buffer, ctx->bufcnt);
+ if (err)
+ goto exit;
+ }
+
+ if (unlikely(ctx->flags & FLAGS_BYPASS))
+ err = crypto_shash_final(&_ctx->fallback, out);
+ else
+ err = omap_sha1_md5_final(ctx);
+
+exit:
+ omap_sha1_md5_hw_cleanup(ctx, out);
+
+ return err;
+}
+
+static int omap_shash_finup(struct shash_desc *desc, const u8 *data,
+ size_t length, u8 *out)
+{
+ struct omap_sha1_md5_ctx *ctx = crypto_shash_ctx(desc->tfm);
+ int err1, err2;
+
+ pr_debug("length: %d\n", length);
+
+ ctx->flags |= FLAGS_FINUP;
+
+ err1 = omap_shash_update(desc, data, length);
+
+ /*
+ * final() has to be always called to cleanup resources
+ * even if udpate() failed
+ */
+ err2 = omap_shash_final(desc, out);
+
+ return err1 ?: err2;
+}
+
+static int omap_shash_cra_init(struct crypto_tfm *tfm)
+{
+ struct crypto_shash *hash = __crypto_shash_cast(tfm);
+ struct omap_sha1_md5_ctx *ctx = crypto_tfm_ctx(tfm);
+ const char *alg_name = tfm->__crt_alg->cra_name;
+
+ pr_debug("enter\n");
+
+ ctx->req = NULL;
+
+ /* Allocate a fallback and abort if it failed. */
+ ctx->shash_fb = crypto_alloc_shash(alg_name, 0,
+ CRYPTO_ALG_ASYNC |
+ CRYPTO_ALG_NEED_FALLBACK);
+ if (IS_ERR(ctx->shash_fb)) {
+ dev_err(dd->dev, "fallback driver '%s' could not be loaded.\n",
+ alg_name);
+ return PTR_ERR(ctx->shash_fb);
+ }
+
+ hash->descsize += crypto_shash_descsize(ctx->shash_fb);
+
+ return 0;
+}
+
+static void omap_shash_cra_exit(struct crypto_tfm *tfm)
+{
+ struct omap_sha1_md5_ctx *ctx = crypto_tfm_ctx(tfm);
+
+ pr_debug("enter\n");
+ crypto_free_shash(ctx->shash_fb);
+ ctx->shash_fb = NULL;
+ pr_debug("exit\n");
+}
+
+/* ******************** AHASH ********************************************* */
+
+static int omap_ahash_init_bypass(struct omap_sha1_md5_ctx *ctx,
+ struct ahash_request *req)
+{
+ int err = 0;
+ u32 flags;
+
+ pr_debug("length: %d\n", req->nbytes);
+
+ flags = req->base.flags & CRYPTO_TFM_REQ_MAY_SLEEP;
+ ctx->req = ahash_request_alloc(ctx->ahash_fb,
+ flags ? GFP_KERNEL : GFP_ATOMIC);
+ if (!ctx->req) {
+ pr_err("Failed to allocate request\n");
+ return -ENOMEM;
+ }
+
+ ahash_request_set_callback(ctx->req, flags,
+ req->base.complete, req->base.data);
+
+ ahash_request_set_crypt(ctx->req, req->src, req->result,
+ req->nbytes); /* needed before init? */
+ err = crypto_ahash_init(ctx->req);
+
+ ctx->flags &= ~FLAGS_BYPASS_INIT;
+
+ pr_debug("switching to bypass, err: %d\n", err);
+
+ return err;
+}
+
+static int omap_ahash_update_bypass(struct omap_sha1_md5_ctx *ctx,
+ struct ahash_request *req)
+{
+ int err;
+
+ pr_debug("length: %d\n", req->nbytes);
+
+ if (ctx->flags & FLAGS_BYPASS_INIT) {
+ err = omap_ahash_init_bypass(ctx, req);
+ if (err)
+ return err;
+ }
+
+ if (!req->nbytes)
+ return 0;
+
+ ahash_request_set_crypt(ctx->req, req->src, req->result,
+ req->nbytes);
+ err = crypto_ahash_update(ctx->req);
+
+ pr_debug("exit: %d\n", err);
+
+ return err;
+}
+
+static int omap_ahash_init(struct ahash_request *req)
+{
+ struct crypto_ahash *tfm = crypto_ahash_reqtfm(req);
+ struct omap_sha1_md5_ctx *ctx = crypto_ahash_ctx(tfm);
+ int err;
+
+ pr_debug("enter, reqsize: %d\n", tfm->reqsize);
+
+ ctx->digsize = crypto_ahash_digestsize(tfm);
+ ctx->req = req;
+
+ if (req->base.flags & CRYPTO_TFM_REQ_MAY_SLEEP)
+ ctx->flags |= FLAGS_MAY_SLEEP;
+
+ err = omap_sha1_md5_init(ctx);
+
+ pr_debug("exit\n");
+
+ return err;
+
+}
+
+static int omap_ahash_update_dma_fast(struct omap_sha1_md5_ctx *ctx)
+{
+ unsigned int length;
+
+ pr_debug("enter\n");
+
+ ctx->flags |= FLAGS_FAST;
+
+ length = min(ctx->total, sg_dma_len(ctx->sg));
+ ctx->total = length;
+
+ if (!dma_map_sg(dd->dev, ctx->sg, 1, DMA_TO_DEVICE)) {
+ dev_err(dd->dev, "dma_map_sg error\n");
+ return -EINVAL;
+ }
+
+ ctx->total -= length;
+
+ return omap_sha1_md5_xmit_dma(ctx, sg_dma_address(ctx->sg), length, 1);
+}
+
+static int omap_ahash_update_dma(struct omap_sha1_md5_ctx *ctx,
+ struct ahash_request *req)
+{
+ pr_debug("enter\n");
+
+ ctx->req = req;
+ ctx->total = req->nbytes;
+ ctx->sg = req->src;
+ ctx->offset = 0;
+ ctx->length = ctx->sg->length;
+
+ pr_debug("nbytes: %u, digcnt: %d, final: %d\n",
+ ctx->total, ctx->digcnt, (ctx->flags & FLAGS_FINUP) != 0);
+
+ if (sg_is_last(ctx->sg)) {
+ /* may be can use faster functions */
+ int aligned = IS_ALIGNED((u32)ctx->sg->offset, sizeof(u32));
+ int digest = (ctx->flags & FLAGS_FINUP) &&
+ !(ctx->flags & FLAGS_UPDATE);
+ if (digest && aligned)
+ /* digest: first and final */
+ return omap_ahash_update_dma_fast(ctx);
+ }
+
+ return omap_sha1_md5_update_dma_slow(ctx);
+}
+
+static int omap_ahash_update(struct ahash_request *req)
+{
+ struct crypto_ahash *tfm = crypto_ahash_reqtfm(req);
+ struct omap_sha1_md5_ctx *ctx = crypto_ahash_ctx(tfm);
+ int err;
+
+ pr_debug("enter\n");
+
+ if (!req->nbytes)
+ return 0;
+
+ if (ctx->flags & FLAGS_BYPASS)
+ return omap_ahash_update_bypass(ctx, req);
+
+ if ((ctx->flags & FLAGS_FINUP) &&
+ ((ctx->digcnt + ctx->bufcnt + req->nbytes) < 9)) {
+ /* OMAP HW accel works only with buffers >= 9 */
+ /* will switch to bypass in final() */
+ /* final has the same request and data */
+ return 0;
+ }
+
+ init_completion(&dd->dma_wait);
+
+ err = omap_ahash_update_dma(ctx, req);
+
+ ctx->flags |= FLAGS_UPDATE;
+
+ /* wait for dma completion before can take more data */
+ if (!err)
+ err = omap_sha1_md5_wait_for_dma(ctx);
+
+ pr_debug("exit: %d\n", err);
+
+ return err;
+}
+
+static int omap_ahash_final(struct ahash_request *req)
+{
+ struct crypto_ahash *tfm = crypto_ahash_reqtfm(req);
+ struct omap_sha1_md5_ctx *ctx = crypto_ahash_ctx(tfm);
+ int err = 0;
+
+ pr_debug("enter\n");
+
+ ctx->flags |= FLAGS_FINUP;
+
+ /* OMAP HW accel works only with buffers >= 9 */
+ if ((ctx->flags & FLAGS_BYPASS_INIT) ||
+ ((ctx->digcnt + ctx->bufcnt + req->nbytes) < 9 &&
+ !(ctx->flags & FLAGS_BYPASS))) {
+ ctx->flags |= FLAGS_BYPASS;
+ err = omap_ahash_update_bypass(ctx, req);
+ if (err)
+ goto exit;
+ }
+
+ if (unlikely(ctx->flags & FLAGS_BYPASS)) {
+ err = crypto_ahash_final(ctx->req);
+ ahash_request_free(ctx->req);
+ } else {
+ ctx->req = req;
+ err = omap_sha1_md5_final(ctx);
+ }
+
+exit:
+ if (err != -EINPROGRESS)
+ omap_sha1_md5_hw_cleanup(ctx, req->result);
+
+ pr_debug("exit\n");
+
+ return err;
+}
+
+static int omap_ahash_finup(struct ahash_request *req)
+{
+ struct crypto_ahash *tfm = crypto_ahash_reqtfm(req);
+ struct omap_sha1_md5_ctx *ctx = crypto_ahash_ctx(tfm);
+ int err1, err2;
+
+ pr_debug("enter\n");
+ ctx->flags |= FLAGS_FINUP;
+
+ err1 = omap_ahash_update(req);
+ if (err1 == -EINPROGRESS)
+ return err1;
+
+ /*
+ * final() has to be always called to cleanup resources
+ * even if udpate() failed
+ */
+ err2 = omap_ahash_final(req);
+
+ return err1 ?: err2;
+}
+
+static int omap_ahash_digest(struct ahash_request *req)
+{
+ pr_debug("enter\n");
+
+ return omap_ahash_init(req) ?: omap_ahash_finup(req);
+}
+
+static int omap_ahash_cra_init(struct crypto_tfm *tfm)
+{
+ struct crypto_ahash *ahash = __crypto_ahash_cast(tfm);
+ struct omap_sha1_md5_ctx *ctx = crypto_tfm_ctx(tfm);
+ const char *alg_name = tfm->__crt_alg->cra_name;
+
+ pr_debug("enter\n");
+
+ ctx->req = NULL;
+
+ /* Allocate a fallback and abort if it failed. */
+ ctx->ahash_fb = crypto_alloc_ahash(alg_name, 0,
+ CRYPTO_ALG_ASYNC |
+ CRYPTO_ALG_NEED_FALLBACK);
+ if (IS_ERR(ctx->ahash_fb)) {
+ dev_err(dd->dev, "fallback driver '%s' could not be loaded.\n",
+ alg_name);
+ return PTR_ERR(ctx->ahash_fb);
+ }
+
+ pr_debug("ctx size: %d\n", sizeof(*ctx));
+ pr_debug("ahash->reqsize: %d\n", crypto_ahash_reqsize(ahash));
+ pr_debug("fb->reqsize: %d\n", crypto_ahash_reqsize(ctx->ahash_fb));
+
+ return 0;
+}
+
+static void omap_ahash_cra_exit(struct crypto_tfm *tfm)
+{
+ struct omap_sha1_md5_ctx *ctx = crypto_tfm_ctx(tfm);
+
+ pr_debug("enter\n");
+ crypto_free_ahash(ctx->ahash_fb);
+ ctx->ahash_fb = NULL;
+ pr_debug("exit\n");
+}
+
+static struct ahash_alg omap_sha1_aalg = {
+ .init = omap_ahash_init,
+ .update = omap_ahash_update,
+ .final = omap_ahash_final,
+ .finup = omap_ahash_finup,
+ .digest = omap_ahash_digest,
+ .halg.digestsize = SHA1_DIGEST_SIZE,
+ .halg.base = {
+ .cra_name = "sha1",
+ .cra_driver_name = "omap-sha1",
+ .cra_priority = 100,
+ .cra_flags = CRYPTO_ALG_TYPE_AHASH |
+ CRYPTO_ALG_ASYNC |
+ CRYPTO_ALG_NEED_FALLBACK,
+ .cra_blocksize = SHA1_BLOCK_SIZE,
+ .cra_ctxsize = sizeof(struct omap_sha1_md5_ctx),
+ .cra_alignmask = 0,
+ .cra_module = THIS_MODULE,
+ .cra_init = omap_ahash_cra_init,
+ .cra_exit = omap_ahash_cra_exit,
+ }
+};
+
+static struct ahash_alg omap_md5_aalg = {
+ .init = omap_ahash_init,
+ .update = omap_ahash_update,
+ .final = omap_ahash_final,
+ .finup = omap_ahash_finup,
+ .digest = omap_ahash_digest,
+ .halg.digestsize = MD5_DIGEST_SIZE,
+ .halg.base = {
+ .cra_name = "md5",
+ .cra_driver_name = "omap-md5",
+ .cra_priority = 100,
+ .cra_flags = CRYPTO_ALG_TYPE_AHASH |
+ CRYPTO_ALG_ASYNC |
+ CRYPTO_ALG_NEED_FALLBACK,
+ .cra_blocksize = SHA1_BLOCK_SIZE,
+ .cra_ctxsize = sizeof(struct omap_sha1_md5_ctx),
+ .cra_alignmask = 0,
+ .cra_module = THIS_MODULE,
+ .cra_init = omap_ahash_cra_init,
+ .cra_exit = omap_ahash_cra_exit,
+ }
+};
+
+static struct shash_alg omap_sha1_alg = {
+ .digestsize = SHA1_DIGEST_SIZE,
+ .init = omap_shash_init,
+ .update = omap_shash_update,
+ .finup = omap_shash_finup,
+ .final = omap_shash_final,
+ .descsize = sizeof(struct omap_sha1_md5_desc),
+ .base = {
+ .cra_name = "sha1",
+ .cra_driver_name = "omap-sha1",
+ .cra_priority = 100,
+ .cra_flags = CRYPTO_ALG_TYPE_SHASH |
+ CRYPTO_ALG_NEED_FALLBACK,
+ .cra_blocksize = SHA1_BLOCK_SIZE,
+ .cra_ctxsize = sizeof(struct omap_sha1_md5_ctx),
+ .cra_alignmask = 0,
+ .cra_module = THIS_MODULE,
+ .cra_init = omap_shash_cra_init,
+ .cra_exit = omap_shash_cra_exit,
+ }
+};
+
+static struct shash_alg omap_md5_alg = {
+ .digestsize = MD5_DIGEST_SIZE,
+ .init = omap_shash_init,
+ .update = omap_shash_update,
+ .finup = omap_shash_finup,
+ .final = omap_shash_final,
+ .descsize = sizeof(struct omap_sha1_md5_desc),
+ .base = {
+ .cra_name = "md5",
+ .cra_driver_name = "omap-md5",
+ .cra_priority = 100,
+ .cra_flags = CRYPTO_ALG_TYPE_SHASH |
+ CRYPTO_ALG_NEED_FALLBACK,
+ .cra_blocksize = SHA1_MD5_BLOCK_SIZE,
+ .cra_ctxsize = sizeof(struct omap_sha1_md5_ctx),
+ .cra_alignmask = 0,
+ .cra_module = THIS_MODULE,
+ .cra_init = omap_shash_cra_init,
+ .cra_exit = omap_shash_cra_exit,
+ }
+};
+
+static int omap_sha1_md5_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct resource *res;
+ int rc;
+
+ dd = kzalloc(sizeof(struct omap_sha1_md5_dev), GFP_KERNEL);
+ if (dd == NULL) {
+ dev_err(dev, "unable to alloc data struct.\n");
+ rc = -ENOMEM;
+ goto data_err;
+ }
+ dd->dev = dev;
+ platform_set_drvdata(pdev, dd);
+
+ spin_lock_init(&dd->lock);
+ init_waitqueue_head(&dd->wq);
+ tasklet_init(&dd->done_task, omap_sha1_md5_done, (unsigned long)dd);
+
+ /* Get the base address */
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ dev_err(dev, "no MEM resource info\n");
+ rc = -ENODEV;
+ goto res_err;
+ }
+ dd->phys_base = res->start;
+
+ /* Get the DMA */
+ res = platform_get_resource(pdev, IORESOURCE_DMA, 0);
+ if (!res)
+ dev_info(dev, "no DMA resource info\n");
+ else
+ dd->dma = res->start;
+
+ /* for some reason non-dma hash calculation sometimes fails with irq */
+ if (dd->dma) {
+ /* Get the IRQ */
+ res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+ if (!res) {
+ dev_err(dev, "no IRQ resource info\n");
+ rc = -ENODEV;
+ goto res_err;
+ }
+ dd->irq = res->start;
+
+ rc = request_irq(dd->irq, omap_sha1_md5_irq,
+ IRQF_TRIGGER_LOW, DRIVER_NAME, dd);
+ if (rc) {
+ dev_err(dev, "unable to request irq.\n");
+ goto res_err;
+ }
+ }
+
+ /* Initializing the clock */
+ dd->iclk = clk_get(NULL, SHA1_MD5_ICLK);
+ if (!dd->iclk) {
+ dev_err(dev, "clock intialization failed.\n");
+ rc = -ENODEV;
+ goto clk_err;
+ }
+
+ dd->io_base = ioremap(dd->phys_base, SZ_4K);
+ if (!dd->io_base) {
+ dev_err(dev, "can't ioremap\n");
+ rc = -ENOMEM;
+ goto io_err;
+ }
+
+ clk_enable(dd->iclk);
+ dev_info(dev, "hw accel on OMAP rev %u.%u\n",
+ (omap_sha1_md5_read(dd, SHA_REG_REV) & SHA_REG_REV_MAJOR) >> 4,
+ omap_sha1_md5_read(dd, SHA_REG_REV) & SHA_REG_REV_MINOR);
+ clk_disable(dd->iclk);
+
+ /*now register API*/
+ rc = crypto_register_shash(&omap_sha1_alg);
+ if (rc)
+ goto sha1_err;
+ rc = crypto_register_shash(&omap_md5_alg);
+ if (rc)
+ goto md5_err;
+ rc = crypto_register_ahash(&omap_sha1_aalg);
+ if (rc)
+ goto asha1_err;
+ rc = crypto_register_ahash(&omap_md5_aalg);
+ if (rc)
+ goto amd5_err;
+
+ return 0;
+
+amd5_err:
+ crypto_unregister_ahash(&omap_sha1_aalg);
+asha1_err:
+ crypto_unregister_shash(&omap_md5_alg);
+md5_err:
+ crypto_unregister_shash(&omap_sha1_alg);
+sha1_err:
+ iounmap(dd->io_base);
+io_err:
+ clk_put(dd->iclk);
+clk_err:
+ if (dd->irq)
+ free_irq(dd->irq, dd);
+res_err:
+ kfree(dd);
+data_err:
+ dev_err(dev, "initialization failed.\n");
+
+ return rc;
+}
+
+static int omap_sha1_md5_remove(struct platform_device *pdev)
+{
+ crypto_unregister_ahash(&omap_md5_aalg);
+ crypto_unregister_ahash(&omap_sha1_aalg);
+ crypto_unregister_shash(&omap_sha1_alg);
+ crypto_unregister_shash(&omap_md5_alg);
+ tasklet_kill(&dd->done_task);
+ iounmap(dd->io_base);
+ clk_put(dd->iclk);
+ if (dd->irq)
+ free_irq(dd->irq, dd);
+ kfree(dd);
+
+ return 0;
+}
+
+#ifdef CONFIG_ARCH_OMAP24XX
+static struct resource sha1_md5_resources[] = {
+ {
+ .start = OMAP24XX_SEC_SHA1MD5_BASE,
+ .end = OMAP24XX_SEC_SHA1MD5_BASE + 0x64,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = INT_24XX_SHA1MD5,
+ .flags = IORESOURCE_IRQ,
+ }
+};
+#endif
+#ifdef CONFIG_ARCH_OMAP34XX
+static struct resource sha1_md5_resources[] = {
+ {
+ .start = OMAP34XX_SEC_SHA1MD5_BASE,
+ .end = OMAP34XX_SEC_SHA1MD5_BASE + 0x64,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = INT_34XX_SHA1MD52_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .start = OMAP34XX_DMA_SHA1MD5_RX,
+ .flags = IORESOURCE_DMA,
+ }
+};
+#endif
+
+static void omap_sha1_md5_release(struct device *dev)
+{
+}
+
+static struct platform_device sha1_md5_device = {
+ .name = "omap-sha1-md5",
+ .id = -1,
+ .num_resources = ARRAY_SIZE(sha1_md5_resources),
+ .resource = sha1_md5_resources,
+ .dev.release = omap_sha1_md5_release,
+};
+
+static struct platform_driver omap_sha1_md5_driver = {
+ .probe = omap_sha1_md5_probe,
+ .remove = omap_sha1_md5_remove,
+ .driver = {
+ .name = DRIVER_NAME,
+ .owner = THIS_MODULE,
+ },
+};
+
+static int __init omap_sha1_md5_mod_init(void)
+{
+ int ret;
+
+ pr_info("loading %s driver\n", DRIVER_NAME);
+
+ if (!cpu_class_is_omap2() ||
+ omap_type() != OMAP2_DEVICE_TYPE_SEC) {
+ pr_err("Unsupported cpu\n");
+ return -ENODEV;
+ }
+
+ ret = platform_driver_register(&omap_sha1_md5_driver);
+ if (ret)
+ return ret;
+
+ ret = platform_device_register(&sha1_md5_device);
+ if (ret)
+ goto err;
+
+ return 0;
+
+err:
+ platform_driver_unregister(&omap_sha1_md5_driver);
+
+ return ret;
+}
+
+static void __exit omap_sha1_md5_mod_exit(void)
+{
+ platform_device_unregister(&sha1_md5_device);
+ platform_driver_unregister(&omap_sha1_md5_driver);
+}
+
+module_init(omap_sha1_md5_mod_init);
+module_exit(omap_sha1_md5_mod_exit);
+
+MODULE_DESCRIPTION("OMAP SHA1/MD5 hw acceleration support.");
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("David Cohen");
+MODULE_AUTHOR("Dmitry Kasatkin");
+
--
1.6.3.3


2010-03-17 13:12:51

by Dmitry Kasatkin

[permalink] [raw]
Subject: [PATCH 2/2] sec: Makefile/Kconfig update for omap sha1 md5 driver

Signed-off-by: Dmitry Kasatkin <[email protected]>
---
drivers/crypto/Kconfig | 9 +++++++++
drivers/crypto/Makefile | 2 ++
2 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index b08403d..4cca798 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -222,4 +222,13 @@ config CRYPTO_DEV_PPC4XX
help
This option allows you to have support for AMCC crypto acceleration.

+config OMAP_SHA1_MD5
+ tristate "Support for OMAP SHA1/MD5 hw engine"
+ depends on ARCH_OMAP24XX || ARCH_OMAP34XX
+ select CRYPTO_SHA1
+ select CRYPTO_MD5
+ help
+ OMAP processors have SHA1/MD5 module accelerator. Select this if you
+ want to use the OMAP module for SHA1/MD5 algorithms.
+
endif # CRYPTO_HW
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index 6ffcb3f..7e05a82 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -6,3 +6,5 @@ obj-$(CONFIG_CRYPTO_DEV_MV_CESA) += mv_cesa.o
obj-$(CONFIG_CRYPTO_DEV_TALITOS) += talitos.o
obj-$(CONFIG_CRYPTO_DEV_IXP4XX) += ixp4xx_crypto.o
obj-$(CONFIG_CRYPTO_DEV_PPC4XX) += amcc/
+obj-$(CONFIG_OMAP_SHA1_MD5) += omap-sha1-md5.o
+
--
1.6.3.3


2010-03-17 17:08:06

by Felipe Balbi

[permalink] [raw]
Subject: Re: [PATCH 1/2] sec: omap sha1 & md5 driver

On Wed, Mar 17, 2010 at 03:12:50PM +0200, Dmitry Kasatkin wrote:
> Earlier kernel contained omap sha1 and md5 driver, which was not maintained,
> was not ported to new crypto APIs and removed from the source tree.
>
> This driver implements async and sync crypto API.
>
> Signed-off-by: Dmitry Kasatkin <[email protected]>
> ---
> drivers/crypto/omap-sha1-md5.c | 1449 ++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 1449 insertions(+), 0 deletions(-)
> create mode 100644 drivers/crypto/omap-sha1-md5.c
>
> diff --git a/drivers/crypto/omap-sha1-md5.c b/drivers/crypto/omap-sha1-md5.c
> new file mode 100644
> index 0000000..c57c6de
> --- /dev/null
> +++ b/drivers/crypto/omap-sha1-md5.c
> @@ -0,0 +1,1449 @@
> +/*
> + * Cryptographic API.
> + *
> + * Support for OMAP SHA1/MD5 HW acceleration.
> + *
> + * Copyright (c) 2007 Instituto Nokia de Tecnologia - INdT
> + * Authors: David Cohen <[email protected]>
> + * Dmitry Kasatkin <[email protected]>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as published
> + * by the Free Software Foundation.
> + *
> + * This driver is based on padlock-sha.c driver.
> + */
> +
> +#define pr_fmt(fmt) "%s: " fmt, __func__

how about pr_info() and friends ?

> +#include <linux/version.h>
> +#include <linux/err.h>
> +#include <linux/device.h>
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/errno.h>
> +#include <linux/cryptohash.h>
> +#include <linux/interrupt.h>
> +#include <linux/kernel.h>
> +#include <linux/clk.h>
> +#include <linux/irq.h>
> +#include <linux/platform_device.h>
> +#include <linux/scatterlist.h>
> +#include <linux/dma-mapping.h>
> +#include <linux/delay.h>
> +#include <linux/crypto.h>
> +#include <crypto/scatterwalk.h>
> +#include <crypto/algapi.h>
> +#include <crypto/sha.h>
> +#include <crypto/hash.h>
> +#include <crypto/internal/hash.h>
> +
> +#include <plat/cpu.h>
> +#include <plat/dma.h>
> +#include <mach/irqs.h>
> +#include <mach/io.h>
> +
> +/* OMAP3 SHAM2 module */
> +#define OMAP34XX_SEC_SHA1MD5_BASE (L4_34XX_BASE + 0xC3000)

these should come from platform code as a struct resource

> +#define DRIVER_NAME "omap-sha1-md5"

this should be avoided.

> +#ifdef CONFIG_ARCH_OMAP24XX
> +#define SHA1_MD5_ICLK "sha_ick"
> +#endif
> +#ifdef CONFIG_ARCH_OMAP34XX
> +#define SHA1_MD5_ICLK "sha12_ick"
> +#endif

use CLKDEV

> +#define FLAGS_UPDATE 0x0001
> +#define FLAGS_FINUP 0x0002
> +#define FLAGS_FINAL 0x0004
> +#define FLAGS_MAY_SLEEP 0x0008
> +#define FLAGS_BYPASS_INIT 0x0010
> +#define FLAGS_BYPASS 0x0030 /* it's a mask */
> +#define FLAGS_FAST 0x0040
> +#define FLAGS_SHA1 0x0080
> +#define FLAGS_INPROGRESS 0x0100
> +#define FLAGS_DMA_ACTIVE 0x0200
> +#define FLAGS_READY 0x0400
> +#define FLAGS_CLEAN 0x0800
> +#define FLAGS_DMA 0x1000

how about using BIT() macro ?

> +struct omap_sha1_md5_ctx {
> + unsigned long flags;
> + int digsize;
> + size_t bufcnt;
> + size_t digcnt;
> + size_t dma_size;
> + u8 *buffer;
> + size_t buffer_size;
> +
> + /* shash stuff */
> + struct crypto_shash *shash_fb;
> + u8 *data;
> +
> + /* ahash stuff */
> + struct crypto_ahash *ahash_fb;
> + struct ahash_request *req;
> +
> + /* ahash walk state */
> + struct scatterlist *sg;
> + unsigned int offset; /* offset in current sg */
> + unsigned int length; /* length left in current sg */
> + unsigned int total; /* total request */
> +};
> +
> +struct omap_sha1_md5_dev {
> + unsigned long phys_base;
> + struct device *dev;
> + void __iomem *io_base;
> + int irq;
> + struct clk *iclk;
> + struct omap_sha1_md5_ctx *hw_ctx;
> + wait_queue_head_t wq;
> + spinlock_t lock;
> + int dma;
> + dma_addr_t dma_addr;
> + dma_addr_t buffer_addr;
> + int dma_lch;
> + struct completion dma_wait;
> + struct tasklet_struct done_task;
> +};
> +
> +/* device data */
> +static struct omap_sha1_md5_dev *dd;

shouldn't be necessary. You have a platform_device and you already use
platform_set_drvdata(), you already pass it as the dev_id for irq and as
a parameter to tasklet_init()

> +static int omap_sha1_md5_update_dma_slow(struct omap_sha1_md5_ctx *ctx);
> +static int omap_sha1_md5_update_dma_stop(struct omap_sha1_md5_ctx *ctx);
> +static void omap_sha1_md5_hw_cleanup(struct omap_sha1_md5_ctx *ctx, u8 *out);

reorganize the code so you don't need these.

> +static inline u32 omap_sha1_md5_read(struct omap_sha1_md5_dev *dd, u32 offset)
> +{
> + return __raw_readl(dd->io_base + offset);
> +}
> +
> +static inline void omap_sha1_md5_write(struct omap_sha1_md5_dev *dd,
> + u32 offset, u32 value)
> +{
> + __raw_writel(value, dd->io_base + offset);
> +}
> +
> +static void omap_sha1_md5_write_mask(struct omap_sha1_md5_dev *dd, u32 address,
> + u32 value, u32 mask)
> +{
> + u32 val;
> +
> + val = omap_sha1_md5_read(dd, address);
> + val &= ~mask;
> + val |= value;
> + omap_sha1_md5_write(dd, address, val);
> +}
> +
> +static int omap_sha1_md5_wait(struct omap_sha1_md5_dev *dd, u32 offset, u32 bit)
> +{
> + unsigned long timeout = jiffies + DEFAULT_TIMEOUT_INTERVAL;
> +
> + while (!(omap_sha1_md5_read(dd, offset) & bit)) {
> + if (time_is_before_jiffies(timeout))
> + return -ETIMEDOUT;
> + }
> +
> + return 0;
> +}

I'm wondering if you really want a function call just for a busy wait...
how about inlining this function ?

> +static int omap_sha1_md5_wait_for_output_ready(struct omap_sha1_md5_ctx *ctx)
> +{
> + int err;
> +
> + pr_debug("enter\n");

save a dev pointer from the platform_device inside omap_sha1_md5_ctx and
use dev_dbg();

> + if (ctx->flags & FLAGS_READY)
> + return 0;
> +
> + if (ctx->flags & FLAGS_DMA) {
> + unsigned long timeout;
> + if (!(ctx->flags & FLAGS_MAY_SLEEP))
> + return -EINPROGRESS;
> + timeout = wait_event_interruptible_timeout(dd->wq,
> + (ctx->flags & FLAGS_READY),
> + DEFAULT_TIMEOUT_INTERVAL);

if (err < 0)
return err;

> + err = timeout > 0 ? 0 : -ETIMEDOUT;
> + } else {
> + err = omap_sha1_md5_wait(dd, SHA_REG_CTRL,
> + SHA_REG_CTRL_OUTPUT_READY);

if (err < 0)
return err;
> + }
> + pr_debug("exit: %d\n", (omap_sha1_md5_read(dd, SHA_REG_CTRL)
> + & SHA_REG_CTRL_OUTPUT_READY) != 0);

dev_dbg();

> +
> + return err;

return 0;

> +}
> +
> +static irqreturn_t omap_sha1_md5_irq(int irq, void *dev_id)
> +{
> + struct omap_sha1_md5_ctx *ctx = dd->hw_ctx;

struct omap_sha1_md5_ctx *ctx = dev_id;

> + pr_debug("enter\n");

get rid of this line

> + pr_debug("ready: %d\n", (omap_sha1_md5_read(dd, SHA_REG_CTRL) &
> + SHA_REG_CTRL_OUTPUT_READY) != 0);

dev_dbg();

> +
> + if (!ctx) {
> + dev_err(dd->dev, "unknown interrupt.\n");
> + return IRQ_HANDLED;
> + }
> +
> + if (unlikely(ctx->flags & FLAGS_FINAL))
> + /* final -> allow device to go to power-saving mode */
> + omap_sha1_md5_write_mask(dd, SHA_REG_CTRL, 0,
> + SHA_REG_CTRL_LENGTH);
> +
> + omap_sha1_md5_write_mask(dd, SHA_REG_CTRL, SHA_REG_CTRL_OUTPUT_READY,
> + SHA_REG_CTRL_OUTPUT_READY);
> +
> + if (likely(!(ctx->flags & FLAGS_FINAL)))
> + return IRQ_HANDLED;
> +
> + ctx->flags |= FLAGS_READY;
> +
> + pr_debug("DIGEST READY\n");

get rid of this.

> + /* hash is done */
> + if (ctx->flags & FLAGS_MAY_SLEEP)
> + wake_up_interruptible(&dd->wq);
> + else
> + tasklet_schedule(&dd->done_task);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int omap_sha1_md5_wait_for_dma(struct omap_sha1_md5_ctx *ctx)
> +{
> + int err = 0;
> +
> + pr_debug("enter\n");

get rid of this

> + if ((ctx->flags & FLAGS_INPROGRESS) && !(ctx->flags & FLAGS_FINUP)) {
> + unsigned long timeout;
> + if (!(ctx->flags & FLAGS_MAY_SLEEP))
> + return -EINPROGRESS;
> + pr_debug("do wait\n");
> + timeout = wait_for_completion_timeout(&dd->dma_wait,
> + DEFAULT_TIMEOUT_INTERVAL);
> + err = timeout > 0 ? 0 : -ETIMEDOUT;
> + }
> + pr_debug("exit\n");

and this

> +
> + return err;
> +}
> +
> +static void omap_sha1_md5_done(unsigned long data)
> +{
> + struct omap_sha1_md5_ctx *ctx = dd->hw_ctx;

struct omap_sha1_md5_ctx *ctx = (struct omap_sha1_md5_ctx *) data;

> + pr_debug("enter\n");

and this.

> +
> + if (ctx->flags & FLAGS_FINAL)
> + omap_sha1_md5_hw_cleanup(ctx, ctx->req->result);
> +
> + if (ctx->req && ctx->req->base.complete)
> + ctx->req->base.complete(&ctx->req->base, 0);
> +
> + pr_debug("exit\n");

this too.

> +}
> +
> +static void omap_sha1_md5_dma_callback(int lch, u16 ch_status, void *data)
> +{
> + struct omap_sha1_md5_ctx *ctx = dd->hw_ctx;

struct omap_sha1_md5_ctx *ctx = data;

> + pr_debug("enter\n");

this too.

> +
> + ctx->flags &= ~FLAGS_DMA_ACTIVE;
> +
> + omap_sha1_md5_update_dma_stop(ctx);
> + omap_sha1_md5_update_dma_slow(ctx);
> +
> + if (!(ctx->flags & FLAGS_DMA_ACTIVE)) {
> + ctx->flags &= ~FLAGS_INPROGRESS;
> + if (!(ctx->flags & FLAGS_FINAL)) {
> + /* irq handler will complete the the hash */
> + if (ctx->flags & FLAGS_MAY_SLEEP)
> + complete(&dd->dma_wait);
> + else
> + tasklet_schedule(&dd->done_task);
> + }
> + }
> +
> + pr_debug("exit\n");

kill this.

> +}
> +
> +static int omap_sha1_md5_hw_init(struct omap_sha1_md5_ctx *ctx, int use_dma)
> +{
> + int err;
> +
> + pr_debug("enter\n");

and this.

> +static int omap_sha1_md5_xmit_cpu(struct omap_sha1_md5_ctx *ctx,
> + const u8 *buf, size_t length, int final)
> +{
> + int err, count, len32;
> + const u32 *buffer = (const u32 *)buf;

why this ? couldn't you change the function prototype to pass const u32 *
already ?

> + pr_debug("digcnt: %d, length: %d, final: %d\n",
> + ctx->digcnt, length, final);

dev_dbg();

> +static size_t omap_sha1_md5_append_buffer(struct omap_sha1_md5_ctx *ctx,
> + const u8 *data, size_t length)
> +{
> + size_t count = min(length, ctx->buffer_size - ctx->bufcnt);
> +
> + count = min(count, ctx->total);
> + if (count <= 0)
> + return 0;

can min() return a negative ?

> + memcpy(ctx->buffer + ctx->bufcnt, data, count);
> + ctx->bufcnt += count;

add a blank line before return.

> +static int omap_sha1_md5_update_cpu(struct omap_sha1_md5_ctx *ctx,
> + const u8 *data, size_t length)
> +{
> + unsigned int count;
> + int err;
> +
> + pr_debug("enter\n");

get rid of this.

> +
> + if (ctx->bufcnt) {
> + count = min(length, SHA1_MD5_BLOCK_SIZE - ctx->bufcnt);
> + omap_sha1_md5_append_cpu(ctx, data, count);
> + data += count;
> + length -= count;
> + if (!length)
> + return 0;
> + ctx->bufcnt = 0;
> + err = omap_sha1_md5_xmit_cpu(ctx, ctx->buffer,
> + SHA1_MD5_BLOCK_SIZE, 0);
> + if (err)
> + return err;
> + }
> + /* We need to save the last buffer <= 64 to digest it with
> + * CLOSE_HASH = 1 */

multiline comment style is:

/*
* We need to save the last buffer <= 64 to digest it with
* CLOSE_HASH = 1
*/

> +static int omap_sha1_md5_update_dma_slow(struct omap_sha1_md5_ctx *ctx)
> +{
> + unsigned int final;
> + size_t count;
> +
> + pr_debug("enter, total: %d\n", ctx->total);

either get rid of this or change to something really meaningful with
dev_dbg()

> +
> + if (!ctx->total) {
> + pr_debug("no data\n");
> + return 0;
> + }
> +
> + omap_sha1_md5_append_sg(ctx);
> +
> + final = (ctx->flags & FLAGS_FINUP) && !ctx->total;
> +
> + pr_debug("bufcnt: %u, digcnt: %d, final: %d\n",
> + ctx->bufcnt, ctx->digcnt, final);

same here.

> + if (final || (ctx->bufcnt == ctx->buffer_size && ctx->total)) {
> + count = ctx->bufcnt;
> + ctx->bufcnt = 0;
> + return omap_sha1_md5_xmit_dma(ctx, dd->buffer_addr, count,
> + final);
> + }
> +
> + return 0;
> +}
> +
> +static int omap_sha1_md5_update_dma_stop(struct omap_sha1_md5_ctx *ctx)
> +{
> + pr_debug("enter\n");

remove.

> +static int omap_sha1_md5_init(struct omap_sha1_md5_ctx *ctx)
> +{
> + unsigned long flags;
> +
> + pr_debug("enter, digest size: %d\n", ctx->digsize);

either remove or change to something useful with dev_dbg()

> +static int omap_sha1_md5_final(struct omap_sha1_md5_ctx *ctx)
> +{
> + int err = 0, use_dma = !!ctx->req;
> +
> + pr_debug("enter\n");

remove.

> + if (ctx->bufcnt) {
> + /* DMA is overhead if only data is <=64b */
> + if (ctx->bufcnt <= 64)
> + /* still use dma if it has been used already */
> + use_dma = dd->dma_lch >= 0;
> + if (use_dma)
> + err = omap_sha1_md5_xmit_dma(ctx, dd->buffer_addr,
> + ctx->bufcnt, 1);
> + else
> + err = omap_sha1_md5_xmit_cpu(ctx, ctx->buffer,
> + ctx->bufcnt, 1);
> + }
> +
> + if (err)
> + return err;
> +
> + err = omap_sha1_md5_wait_for_output_ready(ctx);
> +
> + pr_debug("exit\n");

and this.

> +
> + return err;
> +}
> +
> +static void omap_sha1_md5_hw_cleanup(struct omap_sha1_md5_ctx *ctx, u8 *out)
> +{
> + unsigned long flags;
> +
> + pr_debug("enter\n");

and this.

> + if (ctx->flags & FLAGS_BYPASS)
> + goto exit;
> +
> + spin_lock_irqsave(&dd->lock, flags);
> + if (ctx->flags & FLAGS_CLEAN) {
> + spin_unlock_irqrestore(&dd->lock, flags);
> + pr_debug("exit: already clean\n");
> + return;
> + }
> + ctx->flags |= FLAGS_CLEAN;
> + spin_unlock_irqrestore(&dd->lock, flags);
> +
> + if (dd->dma_lch >= 0) {
> + /* We can free the channels */
> + omap_free_dma(dd->dma_lch);
> + dd->dma_lch = -1;
> + }
> +
> + omap_sha1_md5_copy_hash(ctx, (u32 *)out);
> + clk_disable(dd->iclk);
> +
> + if (dd->buffer_addr)
> + dma_unmap_single(dd->dev, dd->buffer_addr, ctx->buffer_size,
> + DMA_TO_DEVICE);
> + if (ctx->buffer) {
> + free_page((unsigned long)ctx->buffer);
> + ctx->buffer = NULL;
> + }
> +
> +exit:
> + if (dd->hw_ctx == ctx)
> + dd->hw_ctx = NULL;
> + pr_debug("exit\n");

and this.

> +/* ******************** SHASH ********************************************* */
> +
> +static int omap_shash_update_bypass(struct shash_desc *desc,
> + const u8 *data,
> + size_t length)
> +{
> + struct omap_sha1_md5_ctx *ctx = crypto_shash_ctx(desc->tfm);
> + struct omap_sha1_md5_desc *_ctx = shash_desc_ctx(desc);

this is prone to cause problems when someone tries to play around with
this driver. Could you change the names to something more meaningful ?

at least omap_sha1_md5_desc could be called *desc, maybe...

> + pr_debug("length: %d\n", length);

dev_dbg();

> + if (ctx->flags & FLAGS_BYPASS_INIT) {
> + int err = crypto_shash_init(&_ctx->fallback);
> + pr_debug("switching to bypass, err: %d\n", err);
> + ctx->flags &= ~FLAGS_BYPASS_INIT;
> + if (err)
> + return err;
> + }
> +
> + if (length)
> + return crypto_shash_update(&_ctx->fallback, data, length);
> +
> + return 0;
> +}
> +
> +static int omap_shash_init(struct shash_desc *desc)
> +{
> + struct omap_sha1_md5_ctx *ctx = crypto_shash_ctx(desc->tfm);
> + struct omap_sha1_md5_desc *_ctx = shash_desc_ctx(desc);
> + int err;
> +
> + pr_debug("enter\n");

remove.

> +
> + _ctx->fallback.tfm = ctx->shash_fb;
> + _ctx->fallback.flags = desc->flags & CRYPTO_TFM_REQ_MAY_SLEEP;
> +
> + ctx->digsize = crypto_shash_digestsize(desc->tfm);
> +
> + if (desc->flags & CRYPTO_TFM_REQ_MAY_SLEEP)
> + ctx->flags |= FLAGS_MAY_SLEEP;
> +
> + err = omap_sha1_md5_init(ctx);
> +
> + pr_debug("exit\n");

remove.

> + return err;
> +}
> +
> +static int omap_shash_update(struct shash_desc *desc, const u8 *data,
> + size_t length)
> +{
> + struct omap_sha1_md5_ctx *ctx = crypto_shash_ctx(desc->tfm);
> +
> + pr_debug("length: %d, bypass: %d\n", length,
> + (ctx->flags & FLAGS_BYPASS) != 0);

dev_dbg();

> + if (!length)
> + return 0;
> +
> + if (ctx->flags & FLAGS_BYPASS)
> + return omap_shash_update_bypass(desc, data, length);
> +
> + if ((ctx->flags & FLAGS_FINUP) &&
> + ((ctx->digcnt + ctx->bufcnt + length) < 9)) {
> + /* OMAP HW accel works only with buffers >= 9 */
> + /* will switch to bypass in final() */
> + omap_sha1_md5_append_cpu(ctx, data, length);
> + return 0;
> + }
> +
> + return omap_sha1_md5_update_cpu(ctx, data, length);
> +}
> +
> +static int omap_shash_final(struct shash_desc *desc, u8 *out)
> +{
> + struct omap_sha1_md5_ctx *ctx = crypto_shash_ctx(desc->tfm);
> + struct omap_sha1_md5_desc *_ctx = shash_desc_ctx(desc);
> + int err = 0;
> +
> + pr_debug("enter\n");

remove.

> + ctx->flags |= FLAGS_FINUP;
> +
> + /* OMAP HW accel works only with buffers >= 9 */
> + if ((ctx->flags & FLAGS_BYPASS_INIT) ||
> + ((ctx->digcnt + ctx->bufcnt) < 9 && !(ctx->flags & FLAGS_BYPASS))) {
> + ctx->flags |= FLAGS_BYPASS;
> + err = omap_shash_update_bypass(desc, ctx->buffer, ctx->bufcnt);
> + if (err)
> + goto exit;
> + }
> +
> + if (unlikely(ctx->flags & FLAGS_BYPASS))
> + err = crypto_shash_final(&_ctx->fallback, out);
> + else
> + err = omap_sha1_md5_final(ctx);
> +
> +exit:
> + omap_sha1_md5_hw_cleanup(ctx, out);
> +
> + return err;
> +}
> +
> +static int omap_shash_finup(struct shash_desc *desc, const u8 *data,
> + size_t length, u8 *out)
> +{
> + struct omap_sha1_md5_ctx *ctx = crypto_shash_ctx(desc->tfm);
> + int err1, err2;
> +
> + pr_debug("length: %d\n", length);

dev_dbg() or remove.

> + ctx->flags |= FLAGS_FINUP;
> +
> + err1 = omap_shash_update(desc, data, length);
> +
> + /*
> + * final() has to be always called to cleanup resources
> + * even if udpate() failed
> + */
> + err2 = omap_shash_final(desc, out);
> +
> + return err1 ?: err2;
> +}
> +
> +static int omap_shash_cra_init(struct crypto_tfm *tfm)
> +{
> + struct crypto_shash *hash = __crypto_shash_cast(tfm);
> + struct omap_sha1_md5_ctx *ctx = crypto_tfm_ctx(tfm);
> + const char *alg_name = tfm->__crt_alg->cra_name;
> +
> + pr_debug("enter\n");

remove.

> + ctx->req = NULL;
> +
> + /* Allocate a fallback and abort if it failed. */
> + ctx->shash_fb = crypto_alloc_shash(alg_name, 0,
> + CRYPTO_ALG_ASYNC |
> + CRYPTO_ALG_NEED_FALLBACK);
> + if (IS_ERR(ctx->shash_fb)) {
> + dev_err(dd->dev, "fallback driver '%s' could not be loaded.\n",
> + alg_name);
> + return PTR_ERR(ctx->shash_fb);
> + }
> +
> + hash->descsize += crypto_shash_descsize(ctx->shash_fb);
> +
> + return 0;
> +}
> +
> +static void omap_shash_cra_exit(struct crypto_tfm *tfm)
> +{
> + struct omap_sha1_md5_ctx *ctx = crypto_tfm_ctx(tfm);
> +
> + pr_debug("enter\n");

remove.

> + crypto_free_shash(ctx->shash_fb);
> + ctx->shash_fb = NULL;
> + pr_debug("exit\n");

remove.

> +}
> +
> +/* ******************** AHASH ********************************************* */
> +
> +static int omap_ahash_init_bypass(struct omap_sha1_md5_ctx *ctx,
> + struct ahash_request *req)
> +{
> + int err = 0;
> + u32 flags;
> +
> + pr_debug("length: %d\n", req->nbytes);
> +
> + flags = req->base.flags & CRYPTO_TFM_REQ_MAY_SLEEP;
> + ctx->req = ahash_request_alloc(ctx->ahash_fb,
> + flags ? GFP_KERNEL : GFP_ATOMIC);
> + if (!ctx->req) {
> + pr_err("Failed to allocate request\n");
> + return -ENOMEM;
> + }
> +
> + ahash_request_set_callback(ctx->req, flags,
> + req->base.complete, req->base.data);
> +
> + ahash_request_set_crypt(ctx->req, req->src, req->result,
> + req->nbytes); /* needed before init? */
> + err = crypto_ahash_init(ctx->req);
> +
> + ctx->flags &= ~FLAGS_BYPASS_INIT;
> +
> + pr_debug("switching to bypass, err: %d\n", err);

dev_dbg(). Also do you call err even a possible success ??

> + return err;
> +}
> +
> +static int omap_ahash_update_bypass(struct omap_sha1_md5_ctx *ctx,
> + struct ahash_request *req)
> +{
> + int err;
> +
> + pr_debug("length: %d\n", req->nbytes);

dev_dbg() or remove.

> + if (ctx->flags & FLAGS_BYPASS_INIT) {
> + err = omap_ahash_init_bypass(ctx, req);
> + if (err)
> + return err;
> + }
> +
> + if (!req->nbytes)
> + return 0;
> +
> + ahash_request_set_crypt(ctx->req, req->src, req->result,
> + req->nbytes);
> + err = crypto_ahash_update(ctx->req);
> +
> + pr_debug("exit: %d\n", err);

remove.

> + return err;
> +}
> +
> +static int omap_ahash_init(struct ahash_request *req)
> +{
> + struct crypto_ahash *tfm = crypto_ahash_reqtfm(req);
> + struct omap_sha1_md5_ctx *ctx = crypto_ahash_ctx(tfm);
> + int err;
> +
> + pr_debug("enter, reqsize: %d\n", tfm->reqsize);

dev_dbg() or remove.

> + ctx->digsize = crypto_ahash_digestsize(tfm);
> + ctx->req = req;
> +
> + if (req->base.flags & CRYPTO_TFM_REQ_MAY_SLEEP)
> + ctx->flags |= FLAGS_MAY_SLEEP;
> +
> + err = omap_sha1_md5_init(ctx);
> +
> + pr_debug("exit\n");

remove.

> + return err;
> +
> +}
> +
> +static int omap_ahash_update_dma_fast(struct omap_sha1_md5_ctx *ctx)
> +{
> + unsigned int length;
> +
> + pr_debug("enter\n");

remove.

> + ctx->flags |= FLAGS_FAST;
> +
> + length = min(ctx->total, sg_dma_len(ctx->sg));
> + ctx->total = length;
> +
> + if (!dma_map_sg(dd->dev, ctx->sg, 1, DMA_TO_DEVICE)) {
> + dev_err(dd->dev, "dma_map_sg error\n");
> + return -EINVAL;
> + }
> +
> + ctx->total -= length;
> +
> + return omap_sha1_md5_xmit_dma(ctx, sg_dma_address(ctx->sg), length, 1);
> +}
> +
> +static int omap_ahash_update_dma(struct omap_sha1_md5_ctx *ctx,
> + struct ahash_request *req)
> +{
> + pr_debug("enter\n");

remove.

> + ctx->req = req;
> + ctx->total = req->nbytes;
> + ctx->sg = req->src;
> + ctx->offset = 0;
> + ctx->length = ctx->sg->length;
> +
> + pr_debug("nbytes: %u, digcnt: %d, final: %d\n",
> + ctx->total, ctx->digcnt, (ctx->flags & FLAGS_FINUP) != 0);
> +
> + if (sg_is_last(ctx->sg)) {
> + /* may be can use faster functions */
> + int aligned = IS_ALIGNED((u32)ctx->sg->offset, sizeof(u32));
> + int digest = (ctx->flags & FLAGS_FINUP) &&
> + !(ctx->flags & FLAGS_UPDATE);
> + if (digest && aligned)
> + /* digest: first and final */
> + return omap_ahash_update_dma_fast(ctx);
> + }
> +
> + return omap_sha1_md5_update_dma_slow(ctx);
> +}
> +
> +static int omap_ahash_update(struct ahash_request *req)
> +{
> + struct crypto_ahash *tfm = crypto_ahash_reqtfm(req);
> + struct omap_sha1_md5_ctx *ctx = crypto_ahash_ctx(tfm);
> + int err;
> +
> + pr_debug("enter\n");

remove.

> + if (!req->nbytes)
> + return 0;
> +
> + if (ctx->flags & FLAGS_BYPASS)
> + return omap_ahash_update_bypass(ctx, req);
> +
> + if ((ctx->flags & FLAGS_FINUP) &&
> + ((ctx->digcnt + ctx->bufcnt + req->nbytes) < 9)) {
> + /* OMAP HW accel works only with buffers >= 9 */
> + /* will switch to bypass in final() */
> + /* final has the same request and data */
> + return 0;
> + }
> +
> + init_completion(&dd->dma_wait);
> +
> + err = omap_ahash_update_dma(ctx, req);

if (err) {
dev_dbg(...);
return err;
}

> +
> + ctx->flags |= FLAGS_UPDATE;
> +
> + /* wait for dma completion before can take more data */
> + if (!err)
> + err = omap_sha1_md5_wait_for_dma(ctx);

remove the unnecessary branch on success.

> + pr_debug("exit: %d\n", err);

remove.

> +
> + return err;
> +}
> +
> +static int omap_ahash_final(struct ahash_request *req)
> +{
> + struct crypto_ahash *tfm = crypto_ahash_reqtfm(req);
> + struct omap_sha1_md5_ctx *ctx = crypto_ahash_ctx(tfm);
> + int err = 0;
> +
> + pr_debug("enter\n");

remove.

> +
> + ctx->flags |= FLAGS_FINUP;
> +
> + /* OMAP HW accel works only with buffers >= 9 */
> + if ((ctx->flags & FLAGS_BYPASS_INIT) ||
> + ((ctx->digcnt + ctx->bufcnt + req->nbytes) < 9 &&
> + !(ctx->flags & FLAGS_BYPASS))) {
> + ctx->flags |= FLAGS_BYPASS;
> + err = omap_ahash_update_bypass(ctx, req);
> + if (err)
> + goto exit;
> + }
> +
> + if (unlikely(ctx->flags & FLAGS_BYPASS)) {
> + err = crypto_ahash_final(ctx->req);
> + ahash_request_free(ctx->req);
> + } else {
> + ctx->req = req;
> + err = omap_sha1_md5_final(ctx);
> + }
> +
> +exit:
> + if (err != -EINPROGRESS)
> + omap_sha1_md5_hw_cleanup(ctx, req->result);
> +
> + pr_debug("exit\n");

remove.

> +
> + return err;
> +}
> +
> +static int omap_ahash_finup(struct ahash_request *req)
> +{
> + struct crypto_ahash *tfm = crypto_ahash_reqtfm(req);
> + struct omap_sha1_md5_ctx *ctx = crypto_ahash_ctx(tfm);
> + int err1, err2;
> +
> + pr_debug("enter\n");

remove.

> + ctx->flags |= FLAGS_FINUP;
> +
> + err1 = omap_ahash_update(req);
> + if (err1 == -EINPROGRESS)
> + return err1;
> +
> + /*
> + * final() has to be always called to cleanup resources
> + * even if udpate() failed
> + */
> + err2 = omap_ahash_final(req);
> +
> + return err1 ?: err2;
> +}
> +
> +static int omap_ahash_digest(struct ahash_request *req)
> +{
> + pr_debug("enter\n");

remove.

> + return omap_ahash_init(req) ?: omap_ahash_finup(req);
> +}
> +
> +static int omap_ahash_cra_init(struct crypto_tfm *tfm)
> +{
> + struct crypto_ahash *ahash = __crypto_ahash_cast(tfm);
> + struct omap_sha1_md5_ctx *ctx = crypto_tfm_ctx(tfm);
> + const char *alg_name = tfm->__crt_alg->cra_name;
> +
> + pr_debug("enter\n");

remove.

> + ctx->req = NULL;
> +
> + /* Allocate a fallback and abort if it failed. */
> + ctx->ahash_fb = crypto_alloc_ahash(alg_name, 0,
> + CRYPTO_ALG_ASYNC |
> + CRYPTO_ALG_NEED_FALLBACK);
> + if (IS_ERR(ctx->ahash_fb)) {
> + dev_err(dd->dev, "fallback driver '%s' could not be loaded.\n",
> + alg_name);
> + return PTR_ERR(ctx->ahash_fb);
> + }
> +
> + pr_debug("ctx size: %d\n", sizeof(*ctx));
> + pr_debug("ahash->reqsize: %d\n", crypto_ahash_reqsize(ahash));
> + pr_debug("fb->reqsize: %d\n", crypto_ahash_reqsize(ctx->ahash_fb));

please clean up these.
you shouldn't need so many prints at once and use dev_dbg()

> + return 0;
> +}
> +
> +static void omap_ahash_cra_exit(struct crypto_tfm *tfm)
> +{
> + struct omap_sha1_md5_ctx *ctx = crypto_tfm_ctx(tfm);
> +
> + pr_debug("enter\n");

remove.

> + crypto_free_ahash(ctx->ahash_fb);
> + ctx->ahash_fb = NULL;
> + pr_debug("exit\n");

remove.

> +static int omap_sha1_md5_probe(struct platform_device *pdev)

missing section definition

> +{

static struct omap_sha1_md5_dev *dd;

> + struct device *dev = &pdev->dev;
> + struct resource *res;
> + int rc;
> +
> + dd = kzalloc(sizeof(struct omap_sha1_md5_dev), GFP_KERNEL);
> + if (dd == NULL) {
> + dev_err(dev, "unable to alloc data struct.\n");
> + rc = -ENOMEM;
> + goto data_err;
> + }
> + dd->dev = dev;
> + platform_set_drvdata(pdev, dd);
> +
> + spin_lock_init(&dd->lock);
> + init_waitqueue_head(&dd->wq);
> + tasklet_init(&dd->done_task, omap_sha1_md5_done, (unsigned long)dd);
> +
> + /* Get the base address */
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res) {
> + dev_err(dev, "no MEM resource info\n");
> + rc = -ENODEV;
> + goto res_err;
> + }
> + dd->phys_base = res->start;
> +
> + /* Get the DMA */
> + res = platform_get_resource(pdev, IORESOURCE_DMA, 0);
> + if (!res)
> + dev_info(dev, "no DMA resource info\n");
> + else
> + dd->dma = res->start;
> +
> + /* for some reason non-dma hash calculation sometimes fails with irq */
> + if (dd->dma) {
> + /* Get the IRQ */
> + res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);

platform_get_irq();

> + /* Initializing the clock */
> + dd->iclk = clk_get(NULL, SHA1_MD5_ICLK);

clk_get(&pdev->dev, "ick");

> + dd->io_base = ioremap(dd->phys_base, SZ_4K);
> + if (!dd->io_base) {
> + dev_err(dev, "can't ioremap\n");
> + rc = -ENOMEM;
> + goto io_err;
> + }
> +
> + clk_enable(dd->iclk);
> + dev_info(dev, "hw accel on OMAP rev %u.%u\n",
> + (omap_sha1_md5_read(dd, SHA_REG_REV) & SHA_REG_REV_MAJOR) >> 4,
> + omap_sha1_md5_read(dd, SHA_REG_REV) & SHA_REG_REV_MINOR);

dev_dbg() ??

> + clk_disable(dd->iclk);
> +
> + /*now register API*/

fix the comment style.

> +static int omap_sha1_md5_remove(struct platform_device *pdev)

missing section definition

> +{

static struct omap_sha1_md5_dev *dd = platform_get_drvdata(pdev);

> + crypto_unregister_ahash(&omap_md5_aalg);
> + crypto_unregister_ahash(&omap_sha1_aalg);
> + crypto_unregister_shash(&omap_sha1_alg);
> + crypto_unregister_shash(&omap_md5_alg);
> + tasklet_kill(&dd->done_task);
> + iounmap(dd->io_base);
> + clk_put(dd->iclk);
> + if (dd->irq)
> + free_irq(dd->irq, dd);

0 is a valid irq number.

> + kfree(dd);
> +
> + return 0;
> +}
> +
> +#ifdef CONFIG_ARCH_OMAP24XX
> +static struct resource sha1_md5_resources[] = {
> + {
> + .start = OMAP24XX_SEC_SHA1MD5_BASE,
> + .end = OMAP24XX_SEC_SHA1MD5_BASE + 0x64,
> + .flags = IORESOURCE_MEM,
> + },
> + {
> + .start = INT_24XX_SHA1MD5,
> + .flags = IORESOURCE_IRQ,
> + }
> +};
> +#endif
> +#ifdef CONFIG_ARCH_OMAP34XX
> +static struct resource sha1_md5_resources[] = {
> + {
> + .start = OMAP34XX_SEC_SHA1MD5_BASE,
> + .end = OMAP34XX_SEC_SHA1MD5_BASE + 0x64,
> + .flags = IORESOURCE_MEM,
> + },
> + {
> + .start = INT_34XX_SHA1MD52_IRQ,
> + .flags = IORESOURCE_IRQ,
> + },
> + {
> + .start = OMAP34XX_DMA_SHA1MD5_RX,
> + .flags = IORESOURCE_DMA,
> + }
> +};
> +#endif
> +
> +static void omap_sha1_md5_release(struct device *dev)
> +{
> +}
> +
> +static struct platform_device sha1_md5_device = {
> + .name = "omap-sha1-md5",
> + .id = -1,
> + .num_resources = ARRAY_SIZE(sha1_md5_resources),
> + .resource = sha1_md5_resources,
> + .dev.release = omap_sha1_md5_release,
> +};

the platform_device should come from mach-omap[12]/

> +static struct platform_driver omap_sha1_md5_driver = {
> + .probe = omap_sha1_md5_probe,
> + .remove = omap_sha1_md5_remove,
> + .driver = {
> + .name = DRIVER_NAME,
> + .owner = THIS_MODULE,
> + },
> +};
> +
> +static int __init omap_sha1_md5_mod_init(void)
> +{
> + int ret;
> +
> + pr_info("loading %s driver\n", DRIVER_NAME);
> +
> + if (!cpu_class_is_omap2() ||
> + omap_type() != OMAP2_DEVICE_TYPE_SEC) {
> + pr_err("Unsupported cpu\n");
> + return -ENODEV;
> + }
> +
> + ret = platform_driver_register(&omap_sha1_md5_driver);
> + if (ret)
> + return ret;
> +
> + ret = platform_device_register(&sha1_md5_device);
> + if (ret)
> + goto err;
> +
> + return 0;
> +
> +err:
> + platform_driver_unregister(&omap_sha1_md5_driver);
> +
> + return ret;
> +}

this should be simply:

static int __init omap_sha1_md5_mod_init(void)
{
return platform_driver_register(&omap_sha1_md5_driver);
}

depending on the section you use on probe() it should use
platform_driver_probe(&omap_sha1_md5_driver, omap_sha1_md5_probe)
instead.

> +static void __exit omap_sha1_md5_mod_exit(void)
> +{
> + platform_device_unregister(&sha1_md5_device);

not here.

--
balbi

2010-03-17 20:48:22

by Tony Lindgren

[permalink] [raw]
Subject: Re: [PATCH 1/2] sec: omap sha1 & md5 driver

* Felipe Balbi <[email protected]> [100317 10:04]:
> On Wed, Mar 17, 2010 at 03:12:50PM +0200, Dmitry Kasatkin wrote:
> > Earlier kernel contained omap sha1 and md5 driver, which was not maintained,
> > was not ported to new crypto APIs and removed from the source tree.
>
> > +#include <linux/version.h>
> > +#include <linux/err.h>
> > +#include <linux/device.h>
> > +#include <linux/module.h>
> > +#include <linux/init.h>
> > +#include <linux/errno.h>
> > +#include <linux/cryptohash.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/kernel.h>
> > +#include <linux/clk.h>
> > +#include <linux/irq.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/scatterlist.h>
> > +#include <linux/dma-mapping.h>
> > +#include <linux/delay.h>
> > +#include <linux/crypto.h>
> > +#include <crypto/scatterwalk.h>
> > +#include <crypto/algapi.h>
> > +#include <crypto/sha.h>
> > +#include <crypto/hash.h>
> > +#include <crypto/internal/hash.h>
> > +
> > +#include <plat/cpu.h>
> > +#include <plat/dma.h>
> > +#include <mach/irqs.h>
> > +#include <mach/io.h>
> > +

Please include linux/io.h instead of mach/io.h.

Tony

2010-03-23 12:13:30

by Herbert Xu

[permalink] [raw]
Subject: Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

On Wed, Mar 17, 2010 at 03:12:49PM +0200, Dmitry Kasatkin wrote:
> Earlier kernel contained omap sha1 and md5 driver, which was not maintained,
> was not ported to new crypto APIs and removed from the source tree.
>
> This driver implements async and sync crypto API.
>
> It still contains pr_debug() for debugging purpose.
> Will be remove for integration.
>
> Dmitry Kasatkin (2):
> sec: omap sha1 & md5 driver
> sec: Makefile/Kconfig update for omap sha1 md5 driver

It looks good to me as far as the Crypto API is concerned.

My only question is what's your plan with respect to HMAC? If
you're going to do it in hardware then it's fine as it is.

Otherwise you need to implement export/import and we also need
to add ahash support to hmac.c.

Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

2010-03-24 07:43:32

by Dmitry Kasatkin

[permalink] [raw]
Subject: Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver



On 23/03/10 13:32, ext Herbert Xu wrote:
> On Wed, Mar 17, 2010 at 03:12:49PM +0200, Dmitry Kasatkin wrote:
>
>> Earlier kernel contained omap sha1 and md5 driver, which was not maintained,
>> was not ported to new crypto APIs and removed from the source tree.
>>
>> This driver implements async and sync crypto API.
>>
>> It still contains pr_debug() for debugging purpose.
>> Will be remove for integration.
>>
>> Dmitry Kasatkin (2):
>> sec: omap sha1& md5 driver
>> sec: Makefile/Kconfig update for omap sha1 md5 driver
>>
> It looks good to me as far as the Crypto API is concerned.
>
> My only question is what's your plan with respect to HMAC? If
> you're going to do it in hardware then it's fine as it is.
>
> Otherwise you need to implement export/import and we also need
> to add ahash support to hmac.c.
>
> Thanks,
>

Hello,

Thanks for looking to it.

No hw is not doing hmac.
I need to look to this then.

Will comeback in a while.

- Dmitry




2010-03-24 15:02:50

by Dmitry Kasatkin

[permalink] [raw]
Subject: Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver


On 23/03/10 13:32, ext Herbert Xu wrote:
> On Wed, Mar 17, 2010 at 03:12:49PM +0200, Dmitry Kasatkin wrote:
>
>> Earlier kernel contained omap sha1 and md5 driver, which was not maintained,
>> was not ported to new crypto APIs and removed from the source tree.
>>
>> This driver implements async and sync crypto API.
>>
>> It still contains pr_debug() for debugging purpose.
>> Will be remove for integration.
>>
>> Dmitry Kasatkin (2):
>> sec: omap sha1& md5 driver
>> sec: Makefile/Kconfig update for omap sha1 md5 driver
>>
> It looks good to me as far as the Crypto API is concerned.
>
> My only question is what's your plan with respect to HMAC? If
> you're going to do it in hardware then it's fine as it is.
>
> Otherwise you need to implement export/import and we also need
> to add ahash support to hmac.c.
>
> Thanks,
>

Hello.

Interesting case with hmac.

return crypto_shash_init(&desc.shash) ?:
crypto_shash_update(&desc.shash, ipad, bs) ?:
crypto_shash_export(&desc.shash, ipad) ?:
crypto_shash_init(&desc.shash) ?:
crypto_shash_update(&desc.shash, opad, bs) ?:
crypto_shash_export(&desc.shash, opad);

Basically it does not call final.
Then call init again.

hw has certain limitation that it requires to process last block with
some bit set.
WHen update is called there is no possibility to know that no more
update() will come.
So possible last block is stored and then hashed out from the final.

I see that above code will not work with the driver.
I wonder how intermediate export/import could be done with omap hw.

But if it's not possible, then why not to have hmac(sha1) as just sw.
Anyway hmac should not process as huge amount of data as hash itself.

What is your opinion/advice?

Thank you
- Dmitry



2010-04-08 14:04:21

by Herbert Xu

[permalink] [raw]
Subject: Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

On Tue, Mar 23, 2010 at 07:32:39PM +0800, Herbert Xu wrote:
>
> My only question is what's your plan with respect to HMAC? If
> you're going to do it in hardware then it's fine as it is.
>
> Otherwise you need to implement export/import and we also need
> to add ahash support to hmac.c.

Dmitry, did you answer this before or did it get lost in the mail :)

Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

2010-04-08 14:08:03

by Herbert Xu

[permalink] [raw]
Subject: Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

Hi:

OK so you did answer my question :)

Dmitry Kasatkin <[email protected]> wrote:
>
> Interesting case with hmac.
>
> return crypto_shash_init(&desc.shash) ?:
> crypto_shash_update(&desc.shash, ipad, bs) ?:
> crypto_shash_export(&desc.shash, ipad) ?:
> crypto_shash_init(&desc.shash) ?:
> crypto_shash_update(&desc.shash, opad, bs) ?:
> crypto_shash_export(&desc.shash, opad);
>
> Basically it does not call final.
> Then call init again.
>
> hw has certain limitation that it requires to process last block with
> some bit set.
> WHen update is called there is no possibility to know that no more
> update() will come.
> So possible last block is stored and then hashed out from the final.
>
> I see that above code will not work with the driver.
> I wonder how intermediate export/import could be done with omap hw.
>
> But if it's not possible, then why not to have hmac(sha1) as just sw.
> Anyway hmac should not process as huge amount of data as hash itself.
>
> What is your opinion/advice?

A sha1-only driver is not very useful since the biggest potential
user IPsec uses hmac(sha1).

Is the omap hw documentation available publicly?

Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

2010-04-08 16:41:30

by Dmitry Kasatkin

[permalink] [raw]
Subject: Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

----- Original message -----
> Hi:
>
> OK so you did answer my question :)
>
> Dmitry Kasatkin <[email protected]> wrote:
> >
> > Interesting case with hmac.
> >
> > return crypto_shash_init(&desc.shash) ?:
> > crypto_shash_update(&desc.shash, ipad, bs) ?:
> > crypto_shash_export(&desc.shash, ipad) ?:
> > crypto_shash_init(&desc.shash) ?:
> > crypto_shash_update(&desc.shash, opad, bs) ?:
> > crypto_shash_export(&desc.shash, opad);
> >
> > Basically it does not call final.
> > Then call init again.
> >
> > hw has certain limitation that it requires to process last block with
> > some bit set.
> > WHen update is called there is no possibility to know that no more
> > update() will come.
> > So possible last block is stored and then hashed out from the final.
> >
> > I see that above code will not work with the driver.
> > I wonder how intermediate export/import could be done with omap hw.
> >
> > But if it's not possible, then why not to have hmac(sha1) as just sw.
> > Anyway hmac should not process as huge amount of data as hash itself.
> >
> > What is your opinion/advice?
>
> A sha1-only driver is not very useful since the biggest potential
> user IPsec uses hmac(sha1).
>
> Is the omap hw documentation available publicly?
>
> Thanks,
> --
> Visit Openswan at http://www.openswan.org/
> Email: Herbert Xu ~{PmV>HI~} <[email protected]>
> 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 [email protected]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Hi.

Sha1 only is also very useful. We calcluate hashes of all binaries for integrity verification. We do not need hmac there.

But in general it is possible do add algo hmac(sha1) to the driver and implement it internally without import/export.

I have to check on documentation publicity.

Br,
Dmitry

2010-04-13 08:59:24

by Herbert Xu

[permalink] [raw]
Subject: Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

On Thu, Apr 08, 2010 at 06:35:33PM +0200, [email protected] wrote:
>
> Sha1 only is also very useful. We calcluate hashes of all binaries for integrity verification. We do not need hmac there.

But do we do that in the Linux kernel?

Of course it would be useful if we had a user-space API, but
that is still on the TODO list.

> But in general it is possible do add algo hmac(sha1) to the driver and implement it internally without import/export.

No we don't want to add hmac to every single driver that does
sha1. So this would not be a good precedent. In any case,
some form of import/export must be possible (maybe not in our
current format) because our API requires the ability to perform
a partial update and postpone the finalisation indefinitely.

If you couldn't import/export, that would imply that the hardware
must have infinite memory.

> I have to check on documentation publicity.

Thanks!
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

2010-04-13 09:40:38

by Dmitry Kasatkin

[permalink] [raw]
Subject: Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

Hi,

btw. patch to mv_cesa is actually adding hmac to the driver.
How would you comment that?

The same way could be also used here.
I could calc final output with sw.

Any comments?

- Dmitry



On 13/04/10 11:59, ext Herbert Xu wrote:
> On Thu, Apr 08, 2010 at 06:35:33PM +0200, [email protected] wrote:
>
>> Sha1 only is also very useful. We calcluate hashes of all binaries for integrity verification. We do not need hmac there.
>>
> But do we do that in the Linux kernel?
>
> Of course it would be useful if we had a user-space API, but
> that is still on the TODO list.
>
>
>> But in general it is possible do add algo hmac(sha1) to the driver and implement it internally without import/export.
>>
> No we don't want to add hmac to every single driver that does
> sha1. So this would not be a good precedent. In any case,
> some form of import/export must be possible (maybe not in our
> current format) because our API requires the ability to perform
> a partial update and postpone the finalisation indefinitely.
>
> If you couldn't import/export, that would imply that the hardware
> must have infinite memory.
>
>
>> I have to check on documentation publicity.
>>
> Thanks!
>

2010-04-13 10:03:19

by Herbert Xu

[permalink] [raw]
Subject: Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

On Tue, Apr 13, 2010 at 12:39:55PM +0300, Dmitry Kasatkin wrote:
>
> btw. patch to mv_cesa is actually adding hmac to the driver.
> How would you comment that?

AFAICS it's doing HMAC in hardware. Uri, is that not the case?

> The same way could be also used here.

If your hardware supports HMAC that would definitely be the way
to go.

Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

2010-04-13 10:14:20

by Dmitry Kasatkin

[permalink] [raw]
Subject: Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

Hi

On 13/04/10 13:03, ext Herbert Xu wrote:
> On Tue, Apr 13, 2010 at 12:39:55PM +0300, Dmitry Kasatkin wrote:
>
>> btw. patch to mv_cesa is actually adding hmac to the driver.
>> How would you comment that?
>>
> AFAICS it's doing HMAC in hardware. Uri, is that not the case?
>
>
As I can see from the patch initial vectors calculated with SW shash
Rest is done in hw, basically sha1.

The same can be done with omap driver.
Just in addition to finalize as done in hmac_final().

crypto_shash_import(desc, opad) ?:
crypto_shash_finup(desc, out, ds, req->result);


>> The same way could be also used here.
>>
> If your hardware supports HMAC that would definitely be the way
> to go.
>
> Cheers,
>

2010-04-13 10:16:37

by Dmitry Kasatkin

[permalink] [raw]
Subject: Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

Btw.

But anyway hmac does not support ahash now. right?
So the only way currently is to add to the driver.


On 13/04/10 13:03, ext Herbert Xu wrote:
> On Tue, Apr 13, 2010 at 12:39:55PM +0300, Dmitry Kasatkin wrote:
>
>> btw. patch to mv_cesa is actually adding hmac to the driver.
>> How would you comment that?
>>
> AFAICS it's doing HMAC in hardware. Uri, is that not the case?
>
>
>> The same way could be also used here.
>>
> If your hardware supports HMAC that would definitely be the way
> to go.
>
> Cheers,
>

2010-04-13 12:01:11

by Uri Simchoni

[permalink] [raw]
Subject: Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

The Marvell CESA needs some software assistance in doing HMAC - the inner and outer blocks need
to be prepared and hashed (partial hash). The hash results are fed into the hardware and the hardware uses it
as IVs and does the two hash operations. So in effect the HW hmac(sha1) driver needs software sha1 driver.

Note, however, that the above calculation is not per-request, it is per setkey operation. The IVs are stored in the tfm.

I hope that clears things with respect to the mv_cesa driver.

On 4/13/2010 1:15 PM, Dmitry Kasatkin wrote:
> Btw.
>
> But anyway hmac does not support ahash now. right?
> So the only way currently is to add to the driver.
>
>
> On 13/04/10 13:03, ext Herbert Xu wrote:
>> On Tue, Apr 13, 2010 at 12:39:55PM +0300, Dmitry Kasatkin wrote:
>>
>>> btw. patch to mv_cesa is actually adding hmac to the driver.
>>> How would you comment that?
>>>
>> AFAICS it's doing HMAC in hardware. Uri, is that not the case?
>>
>>
>>> The same way could be also used here.
>>>
>> If your hardware supports HMAC that would definitely be the way
>> to go.
>>
>> Cheers,
>>


2010-04-13 12:02:52

by Herbert Xu

[permalink] [raw]
Subject: Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

On Tue, Apr 13, 2010 at 01:13:47PM +0300, Dmitry Kasatkin wrote:
>
> As I can see from the patch initial vectors calculated with SW shash
> Rest is done in hw, basically sha1.

Ideally that code shouldn't be duplicated either, but honestly
that doesn't matter when it comes to whether the hardware can
do HMAC directly.

You only compute the IVs once for each key, so whether it's done
in software or hardware doesn't matter.

> The same can be done with omap driver.
> Just in addition to finalize as done in hmac_final().

If you do hmac_final in software, then this is no longer a hw
HMAC implementation and we should instead implement an ahash
version of hmac.

The difference here is that ipad/opad is computed only once for
a key, while final happens many times over the lifetime of that
key.

Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

2010-04-13 12:10:14

by Herbert Xu

[permalink] [raw]
Subject: Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

On Tue, Apr 13, 2010 at 01:15:34PM +0300, Dmitry Kasatkin wrote:
>
> But anyway hmac does not support ahash now. right?
> So the only way currently is to add to the driver.

No the only way is to add an ahash version of hmac.

Anyway, the fact that you can't easily implement import/export
is not just a question of supporting hmac. It is in fact a sign
that your driver breaks the crypto API.

The fundamental requirement for the ahash interface is that you
must be able to launch multiple operations, which means that all
state must be stored in the request and not held in hardware
(except as a cache).

IOW, you must be able to support

crypto_ahash_update(&reqa);

...

crypto_ahash_update(&reqb);

...

ahash_request_set_crypt(&reqa, ...);
crypto_ahash_finup(&reqa);

...

ahash_request_set_crypt(&reqb, ...);
crypto_ahash_finup(&reqb);

AFAICS your driver cannot do this correctly in its current form.

Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

2010-04-13 13:00:51

by Dmitry Kasatkin

[permalink] [raw]
Subject: Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

On 13/04/10 15:02, ext Herbert Xu wrote:
> On Tue, Apr 13, 2010 at 01:13:47PM +0300, Dmitry Kasatkin wrote:
>
>> As I can see from the patch initial vectors calculated with SW shash
>> Rest is done in hw, basically sha1.
>>
> Ideally that code shouldn't be duplicated either, but honestly
> that doesn't matter when it comes to whether the hardware can
> do HMAC directly.
>
> You only compute the IVs once for each key, so whether it's done
> in software or hardware doesn't matter.
>
>
>> The same can be done with omap driver.
>> Just in addition to finalize as done in hmac_final().
>>
> If you do hmac_final in software, then this is no longer a hw
> HMAC implementation and we should instead implement an ahash
> version of hmac.
>
> The difference here is that ipad/opad is computed only once for
> a key, while final happens many times over the lifetime of that
> key.
>
>
I do not see your point.
As stated by Uri Simchoni, hw hmac(sha1) in mv_cesa case requires sw
sha1 driver.
Initial vectors are calculated per key by sw.
So it is no longer hw HMAC implementation.

I just want to understand what make it defferent from mv_cesa if in
omap-sham case

hash(opad ∥ hash(ipad ∥ message))

I would also:
1. calc hash(opad) using sw, export
2. hash(ipad ∥ message) using hw
3. then import and finup hash from step 1 with results of step 2 (using sw)

What makes it different from mc_cesa case?


> Cheers,
>

2010-04-13 13:50:54

by Dmitry Kasatkin

[permalink] [raw]
Subject: Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

Please see inline. Nice to clarify it.

On 13/04/10 15:10, ext Herbert Xu wrote:
> On Tue, Apr 13, 2010 at 01:15:34PM +0300, Dmitry Kasatkin wrote:
>
>> But anyway hmac does not support ahash now. right?
>> So the only way currently is to add to the driver.
>>
> No the only way is to add an ahash version of hmac.
>
> Anyway, the fact that you can't easily implement import/export
> is not just a question of supporting hmac. It is in fact a sign
> that your driver breaks the crypto API.
>
> The fundamental requirement for the ahash interface is that you
> must be able to launch multiple operations, which means that all
> state must be stored in the request and not held in hardware
> (except as a cache).
>
> IOW, you must be able to support
>
> crypto_ahash_update(&reqa);
>
> ...
>
> crypto_ahash_update(&reqb);
>
> ...
>
> ahash_request_set_crypt(&reqa, ...);
> crypto_ahash_finup(&reqa);
>
> ...
>
> ahash_request_set_crypt(&reqb, ...);
> crypto_ahash_finup(&reqb);
>
> AFAICS your driver cannot do this correctly in its current form.
>
>
Well it can... if reqa occupied hw all other requests will fallback to
sw sha1.

But if to do only hw and to follow above algorithm then it is necessary
to remove shash support completely from the driver.
And have a queue as I have with aes driver..
err = ablkcipher_enqueue_request(&dd->queue, req);

I see there is ahash_enqueue_request() which is in
crypto/internal/hash.h and NEVER called.

Also in one of your earlier emails you said that it is not possible to
call crypto_ahash_update() before completion.
But with having a queue it does not really matter.
Possible to queue several update request from the same tfm.

The only need to wait_for_completion is to export/get results...

Can you confirm my understanding?

Thanks



Well. not like that.

> Thanks,
>

2010-04-13 14:37:06

by Dmitry Kasatkin

[permalink] [raw]
Subject: Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

Also one more question.

can reqa and reqb could come from the same tfm as well?

thanks

On 13/04/10 16:44, Kasatkin Dmitry (Nokia-D/Helsinki) wrote:
> Please see inline. Nice to clarify it.
>
> On 13/04/10 15:10, ext Herbert Xu wrote:
>
>> On Tue, Apr 13, 2010 at 01:15:34PM +0300, Dmitry Kasatkin wrote:
>>
>>
>>> But anyway hmac does not support ahash now. right?
>>> So the only way currently is to add to the driver.
>>>
>>>
>> No the only way is to add an ahash version of hmac.
>>
>> Anyway, the fact that you can't easily implement import/export
>> is not just a question of supporting hmac. It is in fact a sign
>> that your driver breaks the crypto API.
>>
>> The fundamental requirement for the ahash interface is that you
>> must be able to launch multiple operations, which means that all
>> state must be stored in the request and not held in hardware
>> (except as a cache).
>>
>> IOW, you must be able to support
>>
>> crypto_ahash_update(&reqa);
>>
>> ...
>>
>> crypto_ahash_update(&reqb);
>>
>> ...
>>
>> ahash_request_set_crypt(&reqa, ...);
>> crypto_ahash_finup(&reqa);
>>
>> ...
>>
>> ahash_request_set_crypt(&reqb, ...);
>> crypto_ahash_finup(&reqb);
>>
>> AFAICS your driver cannot do this correctly in its current form.
>>
>>
>>
> Well it can... if reqa occupied hw all other requests will fallback to
> sw sha1.
>
> But if to do only hw and to follow above algorithm then it is necessary
> to remove shash support completely from the driver.
> And have a queue as I have with aes driver..
> err = ablkcipher_enqueue_request(&dd->queue, req);
>
> I see there is ahash_enqueue_request() which is in
> crypto/internal/hash.h and NEVER called.
>
> Also in one of your earlier emails you said that it is not possible to
> call crypto_ahash_update() before completion.
> But with having a queue it does not really matter.
> Possible to queue several update request from the same tfm.
>
> The only need to wait_for_completion is to export/get results...
>
> Can you confirm my understanding?
>
> Thanks
>
>
>
> Well. not like that.
>
>
>> Thanks,
>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>

2010-04-13 14:43:00

by Herbert Xu

[permalink] [raw]
Subject: Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

On Tue, Apr 13, 2010 at 05:36:40PM +0300, Dmitry Kasatkin wrote:
> Also one more question.
>
> can reqa and reqb could come from the same tfm as well?

Yes of course.

Two packets coming from different CPUs going to through the same
IPsec SA for instance.

Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

2010-04-13 14:45:35

by Herbert Xu

[permalink] [raw]
Subject: Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

On Tue, Apr 13, 2010 at 04:00:11PM +0300, Dmitry Kasatkin wrote:
>
> I would also:
> 1. calc hash(opad) using sw, export
> 2. hash(ipad ∥ message) using hw
> 3. then import and finup hash from step 1 with results of step 2 (using sw)

Step 3 is the problem. If you perform step 3 in software then
there is no point in exporting a hmac(sha1) object.

We should instead add ahash support to hmac and use that.

Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

2010-04-13 14:48:53

by Herbert Xu

[permalink] [raw]
Subject: Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

On Tue, Apr 13, 2010 at 04:44:35PM +0300, Dmitry Kasatkin wrote:
>
> Well it can... if reqa occupied hw all other requests will fallback to
> sw sha1.

That is unacceptable. If we had a user-space API that would
mean a single request can tie up the hardware indefinitely.

If your hardware is not able to produce a non-finalised hash,
then you should only do finup/final in hardware, and use a software
fallback to implement the rest.

If your hardware is also not able to accept an initial state,
then the only thing you can implement is digest. The rest would
have to fall back to software.

Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

2010-04-13 15:17:07

by Uri Simchoni

[permalink] [raw]
Subject: Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

Doing step 3 using sw is probably faster than by hw (because it's short and avoid all the hw setup), so the suggested approach is probably faster than generic async hmac.

On 4/13/2010 5:45 PM, Herbert Xu wrote:
> On Tue, Apr 13, 2010 at 04:00:11PM +0300, Dmitry Kasatkin wrote:
>>
>> I would also:
>> 1. calc hash(opad) using sw, export
>> 2. hash(ipad ∥ message) using hw
>> 3. then import and finup hash from step 1 with results of step 2 (using sw)
>
> Step 3 is the problem. If you perform step 3 in software then
> there is no point in exporting a hmac(sha1) object.
>
> We should instead add ahash support to hmac and use that.
>
> Cheers,

2010-04-13 15:22:21

by Dmitry Kasatkin

[permalink] [raw]
Subject: Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver



On 13/04/10 18:16, ext Uri Simchoni wrote:
> Doing step 3 using sw is probably faster than by hw (because it's short and avoid all the hw setup), so the suggested approach is probably faster than generic async hmac.
>
>
Yes. that is exactly what happens in hw - it is much slower.
And I do not see any problems as well with finishing it with sw.


> On 4/13/2010 5:45 PM, Herbert Xu wrote:
>
>> On Tue, Apr 13, 2010 at 04:00:11PM +0300, Dmitry Kasatkin wrote:
>>
>>> I would also:
>>> 1. calc hash(opad) using sw, export
>>> 2. hash(ipad ∥ message) using hw
>>> 3. then import and finup hash from step 1 with results of step 2 (using sw)
>>>
>> Step 3 is the problem. If you perform step 3 in software then
>> there is no point in exporting a hmac(sha1) object.
>>
>> We should instead add ahash support to hmac and use that.
>>
>> Cheers,
>>
>

2010-04-13 15:34:14

by Dmitry Kasatkin

[permalink] [raw]
Subject: Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver



On 13/04/10 17:42, ext Herbert Xu wrote:
> On Tue, Apr 13, 2010 at 05:36:40PM +0300, Dmitry Kasatkin wrote:
>
>> Also one more question.
>>
>> can reqa and reqb could come from the same tfm as well?
>>
> Yes of course.
>
> Two packets coming from different CPUs going to through the same
> IPsec SA for instance.
>
>
Then state must be kept in req ctx, not tfm ctx.
Right?

Then when handling different request HW must be re-initialized.
If handling the same request then no need to reinitialize.

Also not possible to call update(reqa) until previous completed.
Otherwise it will mess up data in reqa.

Thanks

> Cheers,
>

2010-04-13 15:48:57

by Dmitry Kasatkin

[permalink] [raw]
Subject: Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver


About import/export.

The problem with HW is that it always handles 64 byte blocks except last
one.
So until finup/final it is not known if it is the last data. So some
buffer is kept in context.

With DMA it is very inefficient to have small buffer.
I use page 4k for that.
So after a certain update there is a data in the cache.

Doing export means that we need to get out intermediate hash and that
buffer.

Any suggestion?

Thanks


On 13/04/10 17:48, ext Herbert Xu wrote:
> On Tue, Apr 13, 2010 at 04:44:35PM +0300, Dmitry Kasatkin wrote:
>
>> Well it can... if reqa occupied hw all other requests will fallback to
>> sw sha1.
>>
> That is unacceptable. If we had a user-space API that would
> mean a single request can tie up the hardware indefinitely.
>
> If your hardware is not able to produce a non-finalised hash,
> then you should only do finup/final in hardware, and use a software
> fallback to implement the rest.
>
>
> If your hardware is also not able to accept an initial state,
> then the only thing you can implement is digest. The rest would
> have to fall back to software.
>
> Cheers,
>

2010-04-14 00:45:05

by Herbert Xu

[permalink] [raw]
Subject: Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

On Tue, Apr 13, 2010 at 06:21:44PM +0300, Dmitry Kasatkin wrote:
>
>
> On 13/04/10 18:16, ext Uri Simchoni wrote:
>> Doing step 3 using sw is probably faster than by hw (because it's short and avoid all the hw setup), so the suggested approach is probably faster than generic async hmac.
>>
>>
> Yes. that is exactly what happens in hw - it is much slower.
> And I do not see any problems as well with finishing it with sw.

I never said that you can't do it in software. I just don't
want every driver to write its own copy of hmac in software.

If you're going to do it in software, then let's make an ahash
version of hmac.

Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

2010-04-14 00:47:23

by Herbert Xu

[permalink] [raw]
Subject: Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

On Tue, Apr 13, 2010 at 06:33:59PM +0300, Dmitry Kasatkin wrote:
>
> Then state must be kept in req ctx, not tfm ctx.
> Right?

Correct, the same thing applies to both shash and ahash.

> Then when handling different request HW must be re-initialized.
> If handling the same request then no need to reinitialize.

Yes, you're allowed to cache state in the HW so that two requests
in a row that use the same state can avoid reinitialisation.

> Also not possible to call update(reqa) until previous completed.
> Otherwise it will mess up data in reqa.

That is up to the user to enforce. You just need to ensure that
the hardware remains in a sane state even if the user screws up.

Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

2010-04-14 00:50:12

by Herbert Xu

[permalink] [raw]
Subject: Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

On Tue, Apr 13, 2010 at 06:48:42PM +0300, Dmitry Kasatkin wrote:
>
> About import/export.
>
> The problem with HW is that it always handles 64 byte blocks except last
> one.
> So until finup/final it is not known if it is the last data. So some
> buffer is kept in context.
>
> With DMA it is very inefficient to have small buffer.
> I use page 4k for that.
> So after a certain update there is a data in the cache.
>
> Doing export means that we need to get out intermediate hash and that
> buffer.
>
> Any suggestion?

There is no need to buffer extra data in the driver. If we need
to do that that should be done in the upper layer.

So my suggestion would be to feed everything you get in update to
the hardware immediately, unless of course if it's less than a
single block.

Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

2010-04-14 06:38:24

by Dmitry Kasatkin

[permalink] [raw]
Subject: Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver



On 14/04/10 03:44, ext Herbert Xu wrote:
> On Tue, Apr 13, 2010 at 06:21:44PM +0300, Dmitry Kasatkin wrote:
>
>>
>> On 13/04/10 18:16, ext Uri Simchoni wrote:
>>
>>> Doing step 3 using sw is probably faster than by hw (because it's short and avoid all the hw setup), so the suggested approach is probably faster than generic async hmac.
>>>
>>>
>>>
>> Yes. that is exactly what happens in hw - it is much slower.
>> And I do not see any problems as well with finishing it with sw.
>>
> I never said that you can't do it in software. I just don't
> want every driver to write its own copy of hmac in software.
>
>
I understand that it is better to have more "generic" approach and not
duplicate that.
I am not objecting that.

The key point is that we use HW accelerators to get speedup, release CPU
for something else and reduce power consumption (if possible and
specific hw does it more energy efficiently).

Base on above facts hw drivers need to make certain optimization.
And that optimization often does not fit well to the "generic" way.

Like just with import/export.
Problems for hw:

1. To have a good performance with DMA we need to have large buffer.
Not just 64 bytes block. state becomes large

2. supporting concurrent requests means switching HW state and it takes
a time.

All that burden significantly slowdown hw acceleration and increase CPU
load.

I guess my points are understandable.

thanks
> If you're going to do it in software, then let's make an ahash
> version of hmac.
>
> Cheers,
>

2010-04-14 06:44:33

by Herbert Xu

[permalink] [raw]
Subject: Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

On Wed, Apr 14, 2010 at 09:37:47AM +0300, Dmitry Kasatkin wrote:
>
> Like just with import/export.
> Problems for hw:
>
> 1. To have a good performance with DMA we need to have large buffer.
> Not just 64 bytes block. state becomes large

Sure. But it shouldn't be up to the driver to merge operations.
Higher layers (either the end-user or the crypto API) should perform
merging.

We don't put request merging into storage drivers for a reason.

> 2. supporting concurrent requests means switching HW state and it takes
> a time.

Well that's just the way it is. I'm not saying that it's going
to occur frequently, but if it does, you need to support it.

> All that burden significantly slowdown hw acceleration and increase CPU
> load.
>
> I guess my points are understandable.

I understand your concerns, but these are really limitations
common to all off-chip acceleration. If you have to write drivers
for them, then you'll have to deal with these issues.

Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

2010-04-14 06:52:12

by Dmitry Kasatkin

[permalink] [raw]
Subject: Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver



On 14/04/10 09:44, ext Herbert Xu wrote:
> On Wed, Apr 14, 2010 at 09:37:47AM +0300, Dmitry Kasatkin wrote:
>
>> Like just with import/export.
>> Problems for hw:
>>
>> 1. To have a good performance with DMA we need to have large buffer.
>> Not just 64 bytes block. state becomes large
>>
> Sure. But it shouldn't be up to the driver to merge operations.
> Higher layers (either the end-user or the crypto API) should perform
> merging.
>
>
What do you mean by "merge operation".
request merging?

> We don't put request merging into storage drivers for a reason.
>
>
>> 2. supporting concurrent requests means switching HW state and it takes
>> a time.
>>
> Well that's just the way it is. I'm not saying that it's going
> to occur frequently, but if it does, you need to support it.
>
>
>> All that burden significantly slowdown hw acceleration and increase CPU
>> load.
>>
>> I guess my points are understandable.
>>
> I understand your concerns, but these are really limitations
> common to all off-chip acceleration. If you have to write drivers
> for them, then you'll have to deal with these issues.
>
> Cheers,
>

2010-04-14 06:55:08

by Herbert Xu

[permalink] [raw]
Subject: Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

On Wed, Apr 14, 2010 at 09:51:22AM +0300, Dmitry Kasatkin wrote:
>
> What do you mean by "merge operation".
> request merging?

By buffering user data, you're in essence merging requests.

I have no objections to doing that, but let's not do it in every
driver.

Of course, the ultimate solution is for the end-user to produce
requests that do not need merging. So when considering this we
need to be aware of what users are being targeted.

Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

2010-04-16 07:45:35

by Dmitry Kasatkin

[permalink] [raw]
Subject: Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

Hi,

crypto_ahash_update()
crypto_ahash_dinup()
crypto_ahash_final()

obviously might need to return -EINPROGRESS

but can
crypto_ahash_init(req)

be synchronous?

Or it could also return EINPROGRESS, though not sense.

- Dmitry


On 14/04/10 09:55, ext Herbert Xu wrote:
> On Wed, Apr 14, 2010 at 09:51:22AM +0300, Dmitry Kasatkin wrote:
>
>> What do you mean by "merge operation".
>> request merging?
>>
> By buffering user data, you're in essence merging requests.
>
> I have no objections to doing that, but let's not do it in every
> driver.
>
> Of course, the ultimate solution is for the end-user to produce
> requests that do not need merging. So when considering this we
> need to be aware of what users are being targeted.
>
> Thanks,
>

2010-04-19 13:27:42

by Herbert Xu

[permalink] [raw]
Subject: Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

On Fri, Apr 16, 2010 at 10:44:37AM +0300, Dmitry Kasatkin wrote:
> Hi,
>
> crypto_ahash_update()
> crypto_ahash_dinup()
> crypto_ahash_final()
>
> obviously might need to return -EINPROGRESS
>
> but can
> crypto_ahash_init(req)
>
> be synchronous?
>
> Or it could also return EINPROGRESS, though not sense.

crypto_ahash_init is allowed to return EINPROGRESS, but it certainly
doesn't *have* to be asynchronous. Most hardware implementations
should be able to do it synchronously by duplicating a precomputed
initial state.

Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt