Hello Herbert,
these are some fixes to issue pointed out by sparse and dmaengine API
udpates on the recently enabled ux500 hw crypto drivers.
These are based on recent linux-next, and can probably be applied on an
architecture specific branch with your ack, or just skip to the next
merge window.
Thanks,
Fabio
Fabio Baltieri (6):
crypto: ux500/hash: use readl on iomem addresses
crypto: ux500/hash: add missing static qualifiers
crypto: ux500/crypt: add missing __iomem qualifiers
crypto: ux500: use dmaengine_device_control API
crypto: ux500: use dmaengine_prep_slave_sg API
crypto: ux500: use dmaengine_submit API
drivers/crypto/ux500/cryp/cryp.c | 4 ++--
drivers/crypto/ux500/cryp/cryp_core.c | 26 +++++++++++++-------------
drivers/crypto/ux500/hash/hash_core.c | 33 ++++++++++++++++-----------------
3 files changed, 31 insertions(+), 32 deletions(-)
--
1.8.2
Always use readl when reading memory mapped registers.
Signed-off-by: Fabio Baltieri <[email protected]>
---
drivers/crypto/ux500/hash/hash_core.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/crypto/ux500/hash/hash_core.c b/drivers/crypto/ux500/hash/hash_core.c
index f89fe8a..154f437 100644
--- a/drivers/crypto/ux500/hash/hash_core.c
+++ b/drivers/crypto/ux500/hash/hash_core.c
@@ -473,12 +473,12 @@ static void hash_hw_write_key(struct hash_device_data *device_data,
HASH_SET_DIN(&word, nwords);
}
- while (device_data->base->str & HASH_STR_DCAL_MASK)
+ while (readl(&device_data->base->str) & HASH_STR_DCAL_MASK)
cpu_relax();
HASH_SET_DCAL;
- while (device_data->base->str & HASH_STR_DCAL_MASK)
+ while (readl(&device_data->base->str) & HASH_STR_DCAL_MASK)
cpu_relax();
}
@@ -661,7 +661,7 @@ static void hash_messagepad(struct hash_device_data *device_data,
if (index_bytes)
HASH_SET_DIN(message, nwords);
- while (device_data->base->str & HASH_STR_DCAL_MASK)
+ while (readl(&device_data->base->str) & HASH_STR_DCAL_MASK)
cpu_relax();
/* num_of_bytes == 0 => NBLW <- 0 (32 bits valid in DATAIN) */
@@ -676,7 +676,7 @@ static void hash_messagepad(struct hash_device_data *device_data,
(int)(readl_relaxed(&device_data->base->str) &
HASH_STR_NBLW_MASK));
- while (device_data->base->str & HASH_STR_DCAL_MASK)
+ while (readl(&device_data->base->str) & HASH_STR_DCAL_MASK)
cpu_relax();
}
@@ -776,7 +776,7 @@ void hash_begin(struct hash_device_data *device_data, struct hash_ctx *ctx)
/* HW and SW initializations */
/* Note: there is no need to initialize buffer and digest members */
- while (device_data->base->str & HASH_STR_DCAL_MASK)
+ while (readl(&device_data->base->str) & HASH_STR_DCAL_MASK)
cpu_relax();
/*
@@ -962,7 +962,7 @@ static int hash_dma_final(struct ahash_request *req)
wait_for_completion(&ctx->device->dma.complete);
hash_dma_done(ctx);
- while (device_data->base->str & HASH_STR_DCAL_MASK)
+ while (readl(&device_data->base->str) & HASH_STR_DCAL_MASK)
cpu_relax();
if (ctx->config.oper_mode == HASH_OPER_MODE_HMAC && ctx->key) {
@@ -1060,7 +1060,7 @@ int hash_hw_final(struct ahash_request *req)
req_ctx->state.index);
} else {
HASH_SET_DCAL;
- while (device_data->base->str & HASH_STR_DCAL_MASK)
+ while (readl(&device_data->base->str) & HASH_STR_DCAL_MASK)
cpu_relax();
}
@@ -1189,7 +1189,7 @@ int hash_resume_state(struct hash_device_data *device_data,
temp_cr = device_state->temp_cr;
writel_relaxed(temp_cr & HASH_CR_RESUME_MASK, &device_data->base->cr);
- if (device_data->base->cr & HASH_CR_MODE_MASK)
+ if (readl(&device_data->base->cr) & HASH_CR_MODE_MASK)
hash_mode = HASH_OPER_MODE_HMAC;
else
hash_mode = HASH_OPER_MODE_HASH;
@@ -1233,7 +1233,7 @@ int hash_save_state(struct hash_device_data *device_data,
* actually makes sure that there isn't any ongoing calculation in the
* hardware.
*/
- while (device_data->base->str & HASH_STR_DCAL_MASK)
+ while (readl(&device_data->base->str) & HASH_STR_DCAL_MASK)
cpu_relax();
temp_cr = readl_relaxed(&device_data->base->cr);
@@ -1242,7 +1242,7 @@ int hash_save_state(struct hash_device_data *device_data,
device_state->din_reg = readl_relaxed(&device_data->base->din);
- if (device_data->base->cr & HASH_CR_MODE_MASK)
+ if (readl(&device_data->base->cr) & HASH_CR_MODE_MASK)
hash_mode = HASH_OPER_MODE_HMAC;
else
hash_mode = HASH_OPER_MODE_HASH;
--
1.8.2
Add missing static qualifiers to hash_process_data and hash_hw_final.
Signed-off-by: Fabio Baltieri <[email protected]>
---
drivers/crypto/ux500/hash/hash_core.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/ux500/hash/hash_core.c b/drivers/crypto/ux500/hash/hash_core.c
index 154f437..dbf7b63 100644
--- a/drivers/crypto/ux500/hash/hash_core.c
+++ b/drivers/crypto/ux500/hash/hash_core.c
@@ -792,8 +792,7 @@ void hash_begin(struct hash_device_data *device_data, struct hash_ctx *ctx)
HASH_CLEAR_BITS(&device_data->base->str, HASH_STR_NBLW_MASK);
}
-int hash_process_data(
- struct hash_device_data *device_data,
+static int hash_process_data(struct hash_device_data *device_data,
struct hash_ctx *ctx, struct hash_req_ctx *req_ctx,
int msg_length, u8 *data_buffer, u8 *buffer, u8 *index)
{
@@ -992,7 +991,7 @@ out:
* hash_hw_final - The final hash calculation function
* @req: The hash request for the job.
*/
-int hash_hw_final(struct ahash_request *req)
+static int hash_hw_final(struct ahash_request *req)
{
int ret = 0;
struct crypto_ahash *tfm = crypto_ahash_reqtfm(req);
--
1.8.2
Use dmaengine_device_control inline function instead of going through the
structures manually.
Signed-off-by: Fabio Baltieri <[email protected]>
---
drivers/crypto/ux500/cryp/cryp_core.c | 4 ++--
drivers/crypto/ux500/hash/hash_core.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/ux500/cryp/cryp_core.c b/drivers/crypto/ux500/cryp/cryp_core.c
index b675bbd..1957c18 100644
--- a/drivers/crypto/ux500/cryp/cryp_core.c
+++ b/drivers/crypto/ux500/cryp/cryp_core.c
@@ -607,12 +607,12 @@ static void cryp_dma_done(struct cryp_ctx *ctx)
dev_dbg(ctx->device->dev, "[%s]: ", __func__);
chan = ctx->device->dma.chan_mem2cryp;
- chan->device->device_control(chan, DMA_TERMINATE_ALL, 0);
+ dmaengine_device_control(chan, DMA_TERMINATE_ALL, 0);
dma_unmap_sg(chan->device->dev, ctx->device->dma.sg_src,
ctx->device->dma.sg_src_len, DMA_TO_DEVICE);
chan = ctx->device->dma.chan_cryp2mem;
- chan->device->device_control(chan, DMA_TERMINATE_ALL, 0);
+ dmaengine_device_control(chan, DMA_TERMINATE_ALL, 0);
dma_unmap_sg(chan->device->dev, ctx->device->dma.sg_dst,
ctx->device->dma.sg_dst_len, DMA_FROM_DEVICE);
}
diff --git a/drivers/crypto/ux500/hash/hash_core.c b/drivers/crypto/ux500/hash/hash_core.c
index dbf7b63..8c2817804 100644
--- a/drivers/crypto/ux500/hash/hash_core.c
+++ b/drivers/crypto/ux500/hash/hash_core.c
@@ -203,7 +203,7 @@ static void hash_dma_done(struct hash_ctx *ctx)
struct dma_chan *chan;
chan = ctx->device->dma.chan_mem2hash;
- chan->device->device_control(chan, DMA_TERMINATE_ALL, 0);
+ dmaengine_device_control(chan, DMA_TERMINATE_ALL, 0);
dma_unmap_sg(chan->device->dev, ctx->device->dma.sg,
ctx->device->dma.sg_len, DMA_TO_DEVICE);
--
1.8.2
Use dmaengine_submit instead of calling desc->tx_submit manually.
Signed-off-by: Fabio Baltieri <[email protected]>
---
drivers/crypto/ux500/cryp/cryp_core.c | 2 +-
drivers/crypto/ux500/hash/hash_core.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/ux500/cryp/cryp_core.c b/drivers/crypto/ux500/cryp/cryp_core.c
index 0cd89df..a999f53 100644
--- a/drivers/crypto/ux500/cryp/cryp_core.c
+++ b/drivers/crypto/ux500/cryp/cryp_core.c
@@ -594,7 +594,7 @@ static int cryp_set_dma_transfer(struct cryp_ctx *ctx,
return -EFAULT;
}
- cookie = desc->tx_submit(desc);
+ cookie = dmaengine_submit(desc);
dma_async_issue_pending(channel);
return 0;
diff --git a/drivers/crypto/ux500/hash/hash_core.c b/drivers/crypto/ux500/hash/hash_core.c
index 3527777..496ae6a 100644
--- a/drivers/crypto/ux500/hash/hash_core.c
+++ b/drivers/crypto/ux500/hash/hash_core.c
@@ -192,7 +192,7 @@ static int hash_set_dma_transfer(struct hash_ctx *ctx, struct scatterlist *sg,
desc->callback = hash_dma_callback;
desc->callback_param = ctx;
- cookie = desc->tx_submit(desc);
+ cookie = dmaengine_submit(desc);
dma_async_issue_pending(channel);
return 0;
--
1.8.2
Use dmaengine_prep_slave_sg inline function instead of going through the
structures manually.
Signed-off-by: Fabio Baltieri <[email protected]>
---
drivers/crypto/ux500/cryp/cryp_core.c | 20 ++++++++++----------
drivers/crypto/ux500/hash/hash_core.c | 4 ++--
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/crypto/ux500/cryp/cryp_core.c b/drivers/crypto/ux500/cryp/cryp_core.c
index 1957c18..0cd89df 100644
--- a/drivers/crypto/ux500/cryp/cryp_core.c
+++ b/drivers/crypto/ux500/cryp/cryp_core.c
@@ -553,10 +553,10 @@ static int cryp_set_dma_transfer(struct cryp_ctx *ctx,
dev_dbg(ctx->device->dev, "[%s]: Setting up DMA for buffer "
"(TO_DEVICE)", __func__);
- desc = channel->device->device_prep_slave_sg(channel,
- ctx->device->dma.sg_src,
- ctx->device->dma.sg_src_len,
- direction, DMA_CTRL_ACK, NULL);
+ desc = dmaengine_prep_slave_sg(channel,
+ ctx->device->dma.sg_src,
+ ctx->device->dma.sg_src_len,
+ direction, DMA_CTRL_ACK);
break;
case DMA_FROM_DEVICE:
@@ -577,12 +577,12 @@ static int cryp_set_dma_transfer(struct cryp_ctx *ctx,
dev_dbg(ctx->device->dev, "[%s]: Setting up DMA for buffer "
"(FROM_DEVICE)", __func__);
- desc = channel->device->device_prep_slave_sg(channel,
- ctx->device->dma.sg_dst,
- ctx->device->dma.sg_dst_len,
- direction,
- DMA_CTRL_ACK |
- DMA_PREP_INTERRUPT, NULL);
+ desc = dmaengine_prep_slave_sg(channel,
+ ctx->device->dma.sg_dst,
+ ctx->device->dma.sg_dst_len,
+ direction,
+ DMA_CTRL_ACK |
+ DMA_PREP_INTERRUPT);
desc->callback = cryp_dma_out_callback;
desc->callback_param = ctx;
diff --git a/drivers/crypto/ux500/hash/hash_core.c b/drivers/crypto/ux500/hash/hash_core.c
index 8c2817804..3527777 100644
--- a/drivers/crypto/ux500/hash/hash_core.c
+++ b/drivers/crypto/ux500/hash/hash_core.c
@@ -180,9 +180,9 @@ static int hash_set_dma_transfer(struct hash_ctx *ctx, struct scatterlist *sg,
dev_dbg(ctx->device->dev, "[%s]: Setting up DMA for buffer "
"(TO_DEVICE)", __func__);
- desc = channel->device->device_prep_slave_sg(channel,
+ desc = dmaengine_prep_slave_sg(channel,
ctx->device->dma.sg, ctx->device->dma.sg_len,
- direction, DMA_CTRL_ACK | DMA_PREP_INTERRUPT, NULL);
+ direction, DMA_CTRL_ACK | DMA_PREP_INTERRUPT);
if (!desc) {
dev_err(ctx->device->dev,
"[%s]: device_prep_slave_sg() failed!", __func__);
--
1.8.2
Add missing __iomem to struct cryp_register pointers, this solve some
"incorrect type in initializer (different address spaces)" sparse
warnings.
Signed-off-by: Fabio Baltieri <[email protected]>
---
drivers/crypto/ux500/cryp/cryp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/ux500/cryp/cryp.c b/drivers/crypto/ux500/cryp/cryp.c
index 3eafa90..43a0c8a 100644
--- a/drivers/crypto/ux500/cryp/cryp.c
+++ b/drivers/crypto/ux500/cryp/cryp.c
@@ -291,7 +291,7 @@ void cryp_save_device_context(struct cryp_device_data *device_data,
int cryp_mode)
{
enum cryp_algo_mode algomode;
- struct cryp_register *src_reg = device_data->base;
+ struct cryp_register __iomem *src_reg = device_data->base;
struct cryp_config *config =
(struct cryp_config *)device_data->current_ctx;
@@ -349,7 +349,7 @@ void cryp_save_device_context(struct cryp_device_data *device_data,
void cryp_restore_device_context(struct cryp_device_data *device_data,
struct cryp_device_context *ctx)
{
- struct cryp_register *reg = device_data->base;
+ struct cryp_register __iomem *reg = device_data->base;
struct cryp_config *config =
(struct cryp_config *)device_data->current_ctx;
--
1.8.2
On Tue, Jun 25, 2013 at 10:54 AM, Fabio Baltieri
<[email protected]> wrote:
> these are some fixes to issue pointed out by sparse and dmaengine API
> udpates on the recently enabled ux500 hw crypto drivers.
The series:
Acked-by: Linus Walleij <[email protected]>
> These are based on recent linux-next, and can probably be applied on an
> architecture specific branch with your ack, or just skip to the next
> merge window.
I think these depend on the DMA40 fixes that reside in the ARM SoC
tree. If I get Herbert's ACK I can queue them.
They will have to go through that tree or wait for the next merge
window, I think they are not regressions so no hurry.
Yours,
Linus Walleij
On Tue, Jun 25, 2013 at 11:20:50AM +0200, Linus Walleij wrote:
> On Tue, Jun 25, 2013 at 10:54 AM, Fabio Baltieri
> <[email protected]> wrote:
>
> > these are some fixes to issue pointed out by sparse and dmaengine API
> > udpates on the recently enabled ux500 hw crypto drivers.
>
> The series:
> Acked-by: Linus Walleij <[email protected]>
>
> > These are based on recent linux-next, and can probably be applied on an
> > architecture specific branch with your ack, or just skip to the next
> > merge window.
>
> I think these depend on the DMA40 fixes that reside in the ARM SoC
> tree. If I get Herbert's ACK I can queue them.
Sure,
Acked-by: Herbert Xu <[email protected]>
Thanks,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Tue, Jun 25, 2013 at 1:17 PM, Herbert Xu <[email protected]> wrote:
> On Tue, Jun 25, 2013 at 11:20:50AM +0200, Linus Walleij wrote:
>> On Tue, Jun 25, 2013 at 10:54 AM, Fabio Baltieri
>> <[email protected]> wrote:
>>
>> > these are some fixes to issue pointed out by sparse and dmaengine API
>> > udpates on the recently enabled ux500 hw crypto drivers.
>>
>> The series:
>> Acked-by: Linus Walleij <[email protected]>
>>
>> > These are based on recent linux-next, and can probably be applied on an
>> > architecture specific branch with your ack, or just skip to the next
>> > merge window.
>>
>> I think these depend on the DMA40 fixes that reside in the ARM SoC
>> tree. If I get Herbert's ACK I can queue them.
>
> Sure,
>
> Acked-by: Herbert Xu <[email protected]>
OK I'll attempt to queue this up and send it to ARM SoC.
Yours,
Linus Walleij