2019-05-27 06:55:01 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
2016-01-26 12:25:39 +00:00
|
|
|
/*
|
|
|
|
* Handle async block request by crypto hardware engine.
|
|
|
|
*
|
|
|
|
* Copyright (C) 2016 Linaro, Inc.
|
|
|
|
*
|
|
|
|
* Author: Baolin Wang <baolin.wang@linaro.org>
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/err.h>
|
|
|
|
#include <linux/delay.h>
|
2020-08-19 11:58:20 +00:00
|
|
|
#include <linux/device.h>
|
2016-08-31 12:02:57 +00:00
|
|
|
#include <crypto/engine.h>
|
2017-02-01 17:07:51 +00:00
|
|
|
#include <uapi/linux/sched/types.h>
|
2016-01-26 12:25:39 +00:00
|
|
|
#include "internal.h"
|
|
|
|
|
|
|
|
#define CRYPTO_ENGINE_MAX_QLEN 10
|
|
|
|
|
2018-01-26 19:15:30 +00:00
|
|
|
/**
|
|
|
|
* crypto_finalize_request - finalize one request if the request is done
|
|
|
|
* @engine: the hardware engine
|
|
|
|
* @req: the request need to be finalized
|
|
|
|
* @err: error number
|
|
|
|
*/
|
|
|
|
static void crypto_finalize_request(struct crypto_engine *engine,
|
crypto: engine - support for parallel requests based on retry mechanism
Added support for executing multiple requests, in parallel,
for crypto engine based on a retry mechanism.
If hardware was unable to execute a backlog request, enqueue it
back in front of crypto-engine queue, to keep the order
of requests.
A new variable is added, retry_support (this is to keep the
backward compatibility of crypto-engine) , which keeps track
whether the hardware has support for retry mechanism and,
also, if can run multiple requests.
If do_one_request() returns:
>= 0: hardware executed the request successfully;
< 0: this is the old error path. If hardware has support for retry
mechanism, the request is put back in front of crypto-engine queue.
For backwards compatibility, if the retry support is not available,
the crypto-engine will work as before.
If hardware queue is full (-ENOSPC), requeue request regardless
of MAY_BACKLOG flag.
If hardware throws any other error code (like -EIO, -EINVAL,
-ENOMEM, etc.) only MAY_BACKLOG requests are enqueued back into
crypto-engine's queue, since the others can be dropped.
The new crypto_engine_alloc_init_and_set function, initializes
crypto-engine, sets the maximum size for crypto-engine software
queue (not hardcoded anymore) and the retry_support variable
is set, by default, to false.
On crypto_pump_requests(), if do_one_request() returns >= 0,
a new request is send to hardware, until there is no space in
hardware and do_one_request() returns < 0.
By default, retry_support is false and crypto-engine will
work as before - will send requests to hardware,
one-by-one, on crypto_pump_requests(), and complete it, on
crypto_finalize_request(), and so on.
To support multiple requests, in each driver, retry_support
must be set on true, and if do_one_request() returns an error
the request must not be freed, since it will be enqueued back
into crypto-engine's queue.
When all drivers, that use crypto-engine now, will be updated for
retry mechanism, the retry_support variable can be removed.
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-04-28 15:49:04 +00:00
|
|
|
struct crypto_async_request *req, int err)
|
2018-01-26 19:15:30 +00:00
|
|
|
{
|
|
|
|
unsigned long flags;
|
crypto: engine - support for parallel requests based on retry mechanism
Added support for executing multiple requests, in parallel,
for crypto engine based on a retry mechanism.
If hardware was unable to execute a backlog request, enqueue it
back in front of crypto-engine queue, to keep the order
of requests.
A new variable is added, retry_support (this is to keep the
backward compatibility of crypto-engine) , which keeps track
whether the hardware has support for retry mechanism and,
also, if can run multiple requests.
If do_one_request() returns:
>= 0: hardware executed the request successfully;
< 0: this is the old error path. If hardware has support for retry
mechanism, the request is put back in front of crypto-engine queue.
For backwards compatibility, if the retry support is not available,
the crypto-engine will work as before.
If hardware queue is full (-ENOSPC), requeue request regardless
of MAY_BACKLOG flag.
If hardware throws any other error code (like -EIO, -EINVAL,
-ENOMEM, etc.) only MAY_BACKLOG requests are enqueued back into
crypto-engine's queue, since the others can be dropped.
The new crypto_engine_alloc_init_and_set function, initializes
crypto-engine, sets the maximum size for crypto-engine software
queue (not hardcoded anymore) and the retry_support variable
is set, by default, to false.
On crypto_pump_requests(), if do_one_request() returns >= 0,
a new request is send to hardware, until there is no space in
hardware and do_one_request() returns < 0.
By default, retry_support is false and crypto-engine will
work as before - will send requests to hardware,
one-by-one, on crypto_pump_requests(), and complete it, on
crypto_finalize_request(), and so on.
To support multiple requests, in each driver, retry_support
must be set on true, and if do_one_request() returns an error
the request must not be freed, since it will be enqueued back
into crypto-engine's queue.
When all drivers, that use crypto-engine now, will be updated for
retry mechanism, the retry_support variable can be removed.
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-04-28 15:49:04 +00:00
|
|
|
bool finalize_req = false;
|
2018-01-26 19:15:30 +00:00
|
|
|
int ret;
|
|
|
|
struct crypto_engine_ctx *enginectx;
|
|
|
|
|
crypto: engine - support for parallel requests based on retry mechanism
Added support for executing multiple requests, in parallel,
for crypto engine based on a retry mechanism.
If hardware was unable to execute a backlog request, enqueue it
back in front of crypto-engine queue, to keep the order
of requests.
A new variable is added, retry_support (this is to keep the
backward compatibility of crypto-engine) , which keeps track
whether the hardware has support for retry mechanism and,
also, if can run multiple requests.
If do_one_request() returns:
>= 0: hardware executed the request successfully;
< 0: this is the old error path. If hardware has support for retry
mechanism, the request is put back in front of crypto-engine queue.
For backwards compatibility, if the retry support is not available,
the crypto-engine will work as before.
If hardware queue is full (-ENOSPC), requeue request regardless
of MAY_BACKLOG flag.
If hardware throws any other error code (like -EIO, -EINVAL,
-ENOMEM, etc.) only MAY_BACKLOG requests are enqueued back into
crypto-engine's queue, since the others can be dropped.
The new crypto_engine_alloc_init_and_set function, initializes
crypto-engine, sets the maximum size for crypto-engine software
queue (not hardcoded anymore) and the retry_support variable
is set, by default, to false.
On crypto_pump_requests(), if do_one_request() returns >= 0,
a new request is send to hardware, until there is no space in
hardware and do_one_request() returns < 0.
By default, retry_support is false and crypto-engine will
work as before - will send requests to hardware,
one-by-one, on crypto_pump_requests(), and complete it, on
crypto_finalize_request(), and so on.
To support multiple requests, in each driver, retry_support
must be set on true, and if do_one_request() returns an error
the request must not be freed, since it will be enqueued back
into crypto-engine's queue.
When all drivers, that use crypto-engine now, will be updated for
retry mechanism, the retry_support variable can be removed.
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-04-28 15:49:04 +00:00
|
|
|
/*
|
|
|
|
* If hardware cannot enqueue more requests
|
|
|
|
* and retry mechanism is not supported
|
|
|
|
* make sure we are completing the current request
|
|
|
|
*/
|
|
|
|
if (!engine->retry_support) {
|
|
|
|
spin_lock_irqsave(&engine->queue_lock, flags);
|
|
|
|
if (engine->cur_req == req) {
|
|
|
|
finalize_req = true;
|
|
|
|
engine->cur_req = NULL;
|
|
|
|
}
|
|
|
|
spin_unlock_irqrestore(&engine->queue_lock, flags);
|
|
|
|
}
|
2018-01-26 19:15:30 +00:00
|
|
|
|
crypto: engine - support for parallel requests based on retry mechanism
Added support for executing multiple requests, in parallel,
for crypto engine based on a retry mechanism.
If hardware was unable to execute a backlog request, enqueue it
back in front of crypto-engine queue, to keep the order
of requests.
A new variable is added, retry_support (this is to keep the
backward compatibility of crypto-engine) , which keeps track
whether the hardware has support for retry mechanism and,
also, if can run multiple requests.
If do_one_request() returns:
>= 0: hardware executed the request successfully;
< 0: this is the old error path. If hardware has support for retry
mechanism, the request is put back in front of crypto-engine queue.
For backwards compatibility, if the retry support is not available,
the crypto-engine will work as before.
If hardware queue is full (-ENOSPC), requeue request regardless
of MAY_BACKLOG flag.
If hardware throws any other error code (like -EIO, -EINVAL,
-ENOMEM, etc.) only MAY_BACKLOG requests are enqueued back into
crypto-engine's queue, since the others can be dropped.
The new crypto_engine_alloc_init_and_set function, initializes
crypto-engine, sets the maximum size for crypto-engine software
queue (not hardcoded anymore) and the retry_support variable
is set, by default, to false.
On crypto_pump_requests(), if do_one_request() returns >= 0,
a new request is send to hardware, until there is no space in
hardware and do_one_request() returns < 0.
By default, retry_support is false and crypto-engine will
work as before - will send requests to hardware,
one-by-one, on crypto_pump_requests(), and complete it, on
crypto_finalize_request(), and so on.
To support multiple requests, in each driver, retry_support
must be set on true, and if do_one_request() returns an error
the request must not be freed, since it will be enqueued back
into crypto-engine's queue.
When all drivers, that use crypto-engine now, will be updated for
retry mechanism, the retry_support variable can be removed.
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-04-28 15:49:04 +00:00
|
|
|
if (finalize_req || engine->retry_support) {
|
2018-01-26 19:15:30 +00:00
|
|
|
enginectx = crypto_tfm_ctx(req->tfm);
|
crypto: engine - support for parallel requests based on retry mechanism
Added support for executing multiple requests, in parallel,
for crypto engine based on a retry mechanism.
If hardware was unable to execute a backlog request, enqueue it
back in front of crypto-engine queue, to keep the order
of requests.
A new variable is added, retry_support (this is to keep the
backward compatibility of crypto-engine) , which keeps track
whether the hardware has support for retry mechanism and,
also, if can run multiple requests.
If do_one_request() returns:
>= 0: hardware executed the request successfully;
< 0: this is the old error path. If hardware has support for retry
mechanism, the request is put back in front of crypto-engine queue.
For backwards compatibility, if the retry support is not available,
the crypto-engine will work as before.
If hardware queue is full (-ENOSPC), requeue request regardless
of MAY_BACKLOG flag.
If hardware throws any other error code (like -EIO, -EINVAL,
-ENOMEM, etc.) only MAY_BACKLOG requests are enqueued back into
crypto-engine's queue, since the others can be dropped.
The new crypto_engine_alloc_init_and_set function, initializes
crypto-engine, sets the maximum size for crypto-engine software
queue (not hardcoded anymore) and the retry_support variable
is set, by default, to false.
On crypto_pump_requests(), if do_one_request() returns >= 0,
a new request is send to hardware, until there is no space in
hardware and do_one_request() returns < 0.
By default, retry_support is false and crypto-engine will
work as before - will send requests to hardware,
one-by-one, on crypto_pump_requests(), and complete it, on
crypto_finalize_request(), and so on.
To support multiple requests, in each driver, retry_support
must be set on true, and if do_one_request() returns an error
the request must not be freed, since it will be enqueued back
into crypto-engine's queue.
When all drivers, that use crypto-engine now, will be updated for
retry mechanism, the retry_support variable can be removed.
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-04-28 15:49:04 +00:00
|
|
|
if (enginectx->op.prepare_request &&
|
2018-01-26 19:15:30 +00:00
|
|
|
enginectx->op.unprepare_request) {
|
|
|
|
ret = enginectx->op.unprepare_request(engine, req);
|
|
|
|
if (ret)
|
|
|
|
dev_err(engine->dev, "failed to unprepare request\n");
|
|
|
|
}
|
|
|
|
}
|
2022-02-21 12:08:33 +00:00
|
|
|
lockdep_assert_in_softirq();
|
2018-01-26 19:15:30 +00:00
|
|
|
req->complete(req, err);
|
|
|
|
|
|
|
|
kthread_queue_work(engine->kworker, &engine->pump_requests);
|
|
|
|
}
|
|
|
|
|
2016-01-26 12:25:39 +00:00
|
|
|
/**
|
|
|
|
* crypto_pump_requests - dequeue one request from engine queue to process
|
|
|
|
* @engine: the hardware engine
|
|
|
|
* @in_kthread: true if we are in the context of the request pump thread
|
|
|
|
*
|
|
|
|
* This function checks if there is any request in the engine queue that
|
|
|
|
* needs processing and if so call out to the driver to initialize hardware
|
|
|
|
* and handle each request.
|
|
|
|
*/
|
|
|
|
static void crypto_pump_requests(struct crypto_engine *engine,
|
|
|
|
bool in_kthread)
|
|
|
|
{
|
|
|
|
struct crypto_async_request *async_req, *backlog;
|
|
|
|
unsigned long flags;
|
|
|
|
bool was_busy = false;
|
2018-01-26 19:15:30 +00:00
|
|
|
int ret;
|
|
|
|
struct crypto_engine_ctx *enginectx;
|
2016-01-26 12:25:39 +00:00
|
|
|
|
|
|
|
spin_lock_irqsave(&engine->queue_lock, flags);
|
|
|
|
|
|
|
|
/* Make sure we are not already running a request */
|
crypto: engine - support for parallel requests based on retry mechanism
Added support for executing multiple requests, in parallel,
for crypto engine based on a retry mechanism.
If hardware was unable to execute a backlog request, enqueue it
back in front of crypto-engine queue, to keep the order
of requests.
A new variable is added, retry_support (this is to keep the
backward compatibility of crypto-engine) , which keeps track
whether the hardware has support for retry mechanism and,
also, if can run multiple requests.
If do_one_request() returns:
>= 0: hardware executed the request successfully;
< 0: this is the old error path. If hardware has support for retry
mechanism, the request is put back in front of crypto-engine queue.
For backwards compatibility, if the retry support is not available,
the crypto-engine will work as before.
If hardware queue is full (-ENOSPC), requeue request regardless
of MAY_BACKLOG flag.
If hardware throws any other error code (like -EIO, -EINVAL,
-ENOMEM, etc.) only MAY_BACKLOG requests are enqueued back into
crypto-engine's queue, since the others can be dropped.
The new crypto_engine_alloc_init_and_set function, initializes
crypto-engine, sets the maximum size for crypto-engine software
queue (not hardcoded anymore) and the retry_support variable
is set, by default, to false.
On crypto_pump_requests(), if do_one_request() returns >= 0,
a new request is send to hardware, until there is no space in
hardware and do_one_request() returns < 0.
By default, retry_support is false and crypto-engine will
work as before - will send requests to hardware,
one-by-one, on crypto_pump_requests(), and complete it, on
crypto_finalize_request(), and so on.
To support multiple requests, in each driver, retry_support
must be set on true, and if do_one_request() returns an error
the request must not be freed, since it will be enqueued back
into crypto-engine's queue.
When all drivers, that use crypto-engine now, will be updated for
retry mechanism, the retry_support variable can be removed.
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-04-28 15:49:04 +00:00
|
|
|
if (!engine->retry_support && engine->cur_req)
|
2016-01-26 12:25:39 +00:00
|
|
|
goto out;
|
|
|
|
|
|
|
|
/* If another context is idling then defer */
|
|
|
|
if (engine->idling) {
|
2016-10-19 11:54:30 +00:00
|
|
|
kthread_queue_work(engine->kworker, &engine->pump_requests);
|
2016-01-26 12:25:39 +00:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Check if the engine queue is idle */
|
|
|
|
if (!crypto_queue_len(&engine->queue) || !engine->running) {
|
|
|
|
if (!engine->busy)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
/* Only do teardown in the thread */
|
|
|
|
if (!in_kthread) {
|
2016-10-19 11:54:30 +00:00
|
|
|
kthread_queue_work(engine->kworker,
|
2016-01-26 12:25:39 +00:00
|
|
|
&engine->pump_requests);
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
engine->busy = false;
|
|
|
|
engine->idling = true;
|
|
|
|
spin_unlock_irqrestore(&engine->queue_lock, flags);
|
|
|
|
|
|
|
|
if (engine->unprepare_crypt_hardware &&
|
|
|
|
engine->unprepare_crypt_hardware(engine))
|
2017-06-06 13:44:16 +00:00
|
|
|
dev_err(engine->dev, "failed to unprepare crypt hardware\n");
|
2016-01-26 12:25:39 +00:00
|
|
|
|
|
|
|
spin_lock_irqsave(&engine->queue_lock, flags);
|
|
|
|
engine->idling = false;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
crypto: engine - support for parallel requests based on retry mechanism
Added support for executing multiple requests, in parallel,
for crypto engine based on a retry mechanism.
If hardware was unable to execute a backlog request, enqueue it
back in front of crypto-engine queue, to keep the order
of requests.
A new variable is added, retry_support (this is to keep the
backward compatibility of crypto-engine) , which keeps track
whether the hardware has support for retry mechanism and,
also, if can run multiple requests.
If do_one_request() returns:
>= 0: hardware executed the request successfully;
< 0: this is the old error path. If hardware has support for retry
mechanism, the request is put back in front of crypto-engine queue.
For backwards compatibility, if the retry support is not available,
the crypto-engine will work as before.
If hardware queue is full (-ENOSPC), requeue request regardless
of MAY_BACKLOG flag.
If hardware throws any other error code (like -EIO, -EINVAL,
-ENOMEM, etc.) only MAY_BACKLOG requests are enqueued back into
crypto-engine's queue, since the others can be dropped.
The new crypto_engine_alloc_init_and_set function, initializes
crypto-engine, sets the maximum size for crypto-engine software
queue (not hardcoded anymore) and the retry_support variable
is set, by default, to false.
On crypto_pump_requests(), if do_one_request() returns >= 0,
a new request is send to hardware, until there is no space in
hardware and do_one_request() returns < 0.
By default, retry_support is false and crypto-engine will
work as before - will send requests to hardware,
one-by-one, on crypto_pump_requests(), and complete it, on
crypto_finalize_request(), and so on.
To support multiple requests, in each driver, retry_support
must be set on true, and if do_one_request() returns an error
the request must not be freed, since it will be enqueued back
into crypto-engine's queue.
When all drivers, that use crypto-engine now, will be updated for
retry mechanism, the retry_support variable can be removed.
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-04-28 15:49:04 +00:00
|
|
|
start_request:
|
2016-01-26 12:25:39 +00:00
|
|
|
/* Get the fist request from the engine queue to handle */
|
|
|
|
backlog = crypto_get_backlog(&engine->queue);
|
|
|
|
async_req = crypto_dequeue_request(&engine->queue);
|
|
|
|
if (!async_req)
|
|
|
|
goto out;
|
|
|
|
|
crypto: engine - support for parallel requests based on retry mechanism
Added support for executing multiple requests, in parallel,
for crypto engine based on a retry mechanism.
If hardware was unable to execute a backlog request, enqueue it
back in front of crypto-engine queue, to keep the order
of requests.
A new variable is added, retry_support (this is to keep the
backward compatibility of crypto-engine) , which keeps track
whether the hardware has support for retry mechanism and,
also, if can run multiple requests.
If do_one_request() returns:
>= 0: hardware executed the request successfully;
< 0: this is the old error path. If hardware has support for retry
mechanism, the request is put back in front of crypto-engine queue.
For backwards compatibility, if the retry support is not available,
the crypto-engine will work as before.
If hardware queue is full (-ENOSPC), requeue request regardless
of MAY_BACKLOG flag.
If hardware throws any other error code (like -EIO, -EINVAL,
-ENOMEM, etc.) only MAY_BACKLOG requests are enqueued back into
crypto-engine's queue, since the others can be dropped.
The new crypto_engine_alloc_init_and_set function, initializes
crypto-engine, sets the maximum size for crypto-engine software
queue (not hardcoded anymore) and the retry_support variable
is set, by default, to false.
On crypto_pump_requests(), if do_one_request() returns >= 0,
a new request is send to hardware, until there is no space in
hardware and do_one_request() returns < 0.
By default, retry_support is false and crypto-engine will
work as before - will send requests to hardware,
one-by-one, on crypto_pump_requests(), and complete it, on
crypto_finalize_request(), and so on.
To support multiple requests, in each driver, retry_support
must be set on true, and if do_one_request() returns an error
the request must not be freed, since it will be enqueued back
into crypto-engine's queue.
When all drivers, that use crypto-engine now, will be updated for
retry mechanism, the retry_support variable can be removed.
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-04-28 15:49:04 +00:00
|
|
|
/*
|
|
|
|
* If hardware doesn't support the retry mechanism,
|
|
|
|
* keep track of the request we are processing now.
|
|
|
|
* We'll need it on completion (crypto_finalize_request).
|
|
|
|
*/
|
|
|
|
if (!engine->retry_support)
|
|
|
|
engine->cur_req = async_req;
|
|
|
|
|
2016-01-26 12:25:39 +00:00
|
|
|
if (backlog)
|
|
|
|
backlog->complete(backlog, -EINPROGRESS);
|
|
|
|
|
|
|
|
if (engine->busy)
|
|
|
|
was_busy = true;
|
|
|
|
else
|
|
|
|
engine->busy = true;
|
|
|
|
|
|
|
|
spin_unlock_irqrestore(&engine->queue_lock, flags);
|
|
|
|
|
|
|
|
/* Until here we get the request need to be encrypted successfully */
|
|
|
|
if (!was_busy && engine->prepare_crypt_hardware) {
|
|
|
|
ret = engine->prepare_crypt_hardware(engine);
|
|
|
|
if (ret) {
|
2017-06-06 13:44:16 +00:00
|
|
|
dev_err(engine->dev, "failed to prepare crypt hardware\n");
|
crypto: engine - support for parallel requests based on retry mechanism
Added support for executing multiple requests, in parallel,
for crypto engine based on a retry mechanism.
If hardware was unable to execute a backlog request, enqueue it
back in front of crypto-engine queue, to keep the order
of requests.
A new variable is added, retry_support (this is to keep the
backward compatibility of crypto-engine) , which keeps track
whether the hardware has support for retry mechanism and,
also, if can run multiple requests.
If do_one_request() returns:
>= 0: hardware executed the request successfully;
< 0: this is the old error path. If hardware has support for retry
mechanism, the request is put back in front of crypto-engine queue.
For backwards compatibility, if the retry support is not available,
the crypto-engine will work as before.
If hardware queue is full (-ENOSPC), requeue request regardless
of MAY_BACKLOG flag.
If hardware throws any other error code (like -EIO, -EINVAL,
-ENOMEM, etc.) only MAY_BACKLOG requests are enqueued back into
crypto-engine's queue, since the others can be dropped.
The new crypto_engine_alloc_init_and_set function, initializes
crypto-engine, sets the maximum size for crypto-engine software
queue (not hardcoded anymore) and the retry_support variable
is set, by default, to false.
On crypto_pump_requests(), if do_one_request() returns >= 0,
a new request is send to hardware, until there is no space in
hardware and do_one_request() returns < 0.
By default, retry_support is false and crypto-engine will
work as before - will send requests to hardware,
one-by-one, on crypto_pump_requests(), and complete it, on
crypto_finalize_request(), and so on.
To support multiple requests, in each driver, retry_support
must be set on true, and if do_one_request() returns an error
the request must not be freed, since it will be enqueued back
into crypto-engine's queue.
When all drivers, that use crypto-engine now, will be updated for
retry mechanism, the retry_support variable can be removed.
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-04-28 15:49:04 +00:00
|
|
|
goto req_err_2;
|
2016-01-26 12:25:39 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-01-26 19:15:30 +00:00
|
|
|
enginectx = crypto_tfm_ctx(async_req->tfm);
|
|
|
|
|
|
|
|
if (enginectx->op.prepare_request) {
|
|
|
|
ret = enginectx->op.prepare_request(engine, async_req);
|
2016-08-31 12:02:58 +00:00
|
|
|
if (ret) {
|
2018-01-26 19:15:30 +00:00
|
|
|
dev_err(engine->dev, "failed to prepare request: %d\n",
|
|
|
|
ret);
|
crypto: engine - support for parallel requests based on retry mechanism
Added support for executing multiple requests, in parallel,
for crypto engine based on a retry mechanism.
If hardware was unable to execute a backlog request, enqueue it
back in front of crypto-engine queue, to keep the order
of requests.
A new variable is added, retry_support (this is to keep the
backward compatibility of crypto-engine) , which keeps track
whether the hardware has support for retry mechanism and,
also, if can run multiple requests.
If do_one_request() returns:
>= 0: hardware executed the request successfully;
< 0: this is the old error path. If hardware has support for retry
mechanism, the request is put back in front of crypto-engine queue.
For backwards compatibility, if the retry support is not available,
the crypto-engine will work as before.
If hardware queue is full (-ENOSPC), requeue request regardless
of MAY_BACKLOG flag.
If hardware throws any other error code (like -EIO, -EINVAL,
-ENOMEM, etc.) only MAY_BACKLOG requests are enqueued back into
crypto-engine's queue, since the others can be dropped.
The new crypto_engine_alloc_init_and_set function, initializes
crypto-engine, sets the maximum size for crypto-engine software
queue (not hardcoded anymore) and the retry_support variable
is set, by default, to false.
On crypto_pump_requests(), if do_one_request() returns >= 0,
a new request is send to hardware, until there is no space in
hardware and do_one_request() returns < 0.
By default, retry_support is false and crypto-engine will
work as before - will send requests to hardware,
one-by-one, on crypto_pump_requests(), and complete it, on
crypto_finalize_request(), and so on.
To support multiple requests, in each driver, retry_support
must be set on true, and if do_one_request() returns an error
the request must not be freed, since it will be enqueued back
into crypto-engine's queue.
When all drivers, that use crypto-engine now, will be updated for
retry mechanism, the retry_support variable can be removed.
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-04-28 15:49:04 +00:00
|
|
|
goto req_err_2;
|
2016-08-31 12:02:58 +00:00
|
|
|
}
|
2018-01-26 19:15:30 +00:00
|
|
|
}
|
|
|
|
if (!enginectx->op.do_one_request) {
|
|
|
|
dev_err(engine->dev, "failed to do request\n");
|
|
|
|
ret = -EINVAL;
|
crypto: engine - support for parallel requests based on retry mechanism
Added support for executing multiple requests, in parallel,
for crypto engine based on a retry mechanism.
If hardware was unable to execute a backlog request, enqueue it
back in front of crypto-engine queue, to keep the order
of requests.
A new variable is added, retry_support (this is to keep the
backward compatibility of crypto-engine) , which keeps track
whether the hardware has support for retry mechanism and,
also, if can run multiple requests.
If do_one_request() returns:
>= 0: hardware executed the request successfully;
< 0: this is the old error path. If hardware has support for retry
mechanism, the request is put back in front of crypto-engine queue.
For backwards compatibility, if the retry support is not available,
the crypto-engine will work as before.
If hardware queue is full (-ENOSPC), requeue request regardless
of MAY_BACKLOG flag.
If hardware throws any other error code (like -EIO, -EINVAL,
-ENOMEM, etc.) only MAY_BACKLOG requests are enqueued back into
crypto-engine's queue, since the others can be dropped.
The new crypto_engine_alloc_init_and_set function, initializes
crypto-engine, sets the maximum size for crypto-engine software
queue (not hardcoded anymore) and the retry_support variable
is set, by default, to false.
On crypto_pump_requests(), if do_one_request() returns >= 0,
a new request is send to hardware, until there is no space in
hardware and do_one_request() returns < 0.
By default, retry_support is false and crypto-engine will
work as before - will send requests to hardware,
one-by-one, on crypto_pump_requests(), and complete it, on
crypto_finalize_request(), and so on.
To support multiple requests, in each driver, retry_support
must be set on true, and if do_one_request() returns an error
the request must not be freed, since it will be enqueued back
into crypto-engine's queue.
When all drivers, that use crypto-engine now, will be updated for
retry mechanism, the retry_support variable can be removed.
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-04-28 15:49:04 +00:00
|
|
|
goto req_err_1;
|
2016-01-26 12:25:39 +00:00
|
|
|
}
|
crypto: engine - support for parallel requests based on retry mechanism
Added support for executing multiple requests, in parallel,
for crypto engine based on a retry mechanism.
If hardware was unable to execute a backlog request, enqueue it
back in front of crypto-engine queue, to keep the order
of requests.
A new variable is added, retry_support (this is to keep the
backward compatibility of crypto-engine) , which keeps track
whether the hardware has support for retry mechanism and,
also, if can run multiple requests.
If do_one_request() returns:
>= 0: hardware executed the request successfully;
< 0: this is the old error path. If hardware has support for retry
mechanism, the request is put back in front of crypto-engine queue.
For backwards compatibility, if the retry support is not available,
the crypto-engine will work as before.
If hardware queue is full (-ENOSPC), requeue request regardless
of MAY_BACKLOG flag.
If hardware throws any other error code (like -EIO, -EINVAL,
-ENOMEM, etc.) only MAY_BACKLOG requests are enqueued back into
crypto-engine's queue, since the others can be dropped.
The new crypto_engine_alloc_init_and_set function, initializes
crypto-engine, sets the maximum size for crypto-engine software
queue (not hardcoded anymore) and the retry_support variable
is set, by default, to false.
On crypto_pump_requests(), if do_one_request() returns >= 0,
a new request is send to hardware, until there is no space in
hardware and do_one_request() returns < 0.
By default, retry_support is false and crypto-engine will
work as before - will send requests to hardware,
one-by-one, on crypto_pump_requests(), and complete it, on
crypto_finalize_request(), and so on.
To support multiple requests, in each driver, retry_support
must be set on true, and if do_one_request() returns an error
the request must not be freed, since it will be enqueued back
into crypto-engine's queue.
When all drivers, that use crypto-engine now, will be updated for
retry mechanism, the retry_support variable can be removed.
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-04-28 15:49:04 +00:00
|
|
|
|
2018-01-26 19:15:30 +00:00
|
|
|
ret = enginectx->op.do_one_request(engine, async_req);
|
crypto: engine - support for parallel requests based on retry mechanism
Added support for executing multiple requests, in parallel,
for crypto engine based on a retry mechanism.
If hardware was unable to execute a backlog request, enqueue it
back in front of crypto-engine queue, to keep the order
of requests.
A new variable is added, retry_support (this is to keep the
backward compatibility of crypto-engine) , which keeps track
whether the hardware has support for retry mechanism and,
also, if can run multiple requests.
If do_one_request() returns:
>= 0: hardware executed the request successfully;
< 0: this is the old error path. If hardware has support for retry
mechanism, the request is put back in front of crypto-engine queue.
For backwards compatibility, if the retry support is not available,
the crypto-engine will work as before.
If hardware queue is full (-ENOSPC), requeue request regardless
of MAY_BACKLOG flag.
If hardware throws any other error code (like -EIO, -EINVAL,
-ENOMEM, etc.) only MAY_BACKLOG requests are enqueued back into
crypto-engine's queue, since the others can be dropped.
The new crypto_engine_alloc_init_and_set function, initializes
crypto-engine, sets the maximum size for crypto-engine software
queue (not hardcoded anymore) and the retry_support variable
is set, by default, to false.
On crypto_pump_requests(), if do_one_request() returns >= 0,
a new request is send to hardware, until there is no space in
hardware and do_one_request() returns < 0.
By default, retry_support is false and crypto-engine will
work as before - will send requests to hardware,
one-by-one, on crypto_pump_requests(), and complete it, on
crypto_finalize_request(), and so on.
To support multiple requests, in each driver, retry_support
must be set on true, and if do_one_request() returns an error
the request must not be freed, since it will be enqueued back
into crypto-engine's queue.
When all drivers, that use crypto-engine now, will be updated for
retry mechanism, the retry_support variable can be removed.
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-04-28 15:49:04 +00:00
|
|
|
|
|
|
|
/* Request unsuccessfully executed by hardware */
|
|
|
|
if (ret < 0) {
|
|
|
|
/*
|
|
|
|
* If hardware queue is full (-ENOSPC), requeue request
|
|
|
|
* regardless of backlog flag.
|
|
|
|
* Otherwise, unprepare and complete the request.
|
|
|
|
*/
|
|
|
|
if (!engine->retry_support ||
|
crypto: engine - do not requeue in case of fatal error
Now, in crypto-engine, if hardware queue is full (-ENOSPC),
requeue request regardless of MAY_BACKLOG flag.
If hardware throws any other error code (like -EIO, -EINVAL,
-ENOMEM, etc.) only MAY_BACKLOG requests are enqueued back into
crypto-engine's queue, since the others can be dropped.
The latter case can be fatal error, so those cannot be recovered from.
For example, in CAAM driver, -EIO is returned in case the job descriptor
is broken, so there is no possibility to fix the job descriptor.
Therefore, these errors might be fatal error, so we shouldn’t
requeue the request. This will just be pass back and forth between
crypto-engine and hardware.
Fixes: 6a89f492f8e5 ("crypto: engine - support for parallel requests based on retry mechanism")
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Reported-by: Horia Geantă <horia.geanta@nxp.com>
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-05-19 22:17:25 +00:00
|
|
|
(ret != -ENOSPC)) {
|
crypto: engine - support for parallel requests based on retry mechanism
Added support for executing multiple requests, in parallel,
for crypto engine based on a retry mechanism.
If hardware was unable to execute a backlog request, enqueue it
back in front of crypto-engine queue, to keep the order
of requests.
A new variable is added, retry_support (this is to keep the
backward compatibility of crypto-engine) , which keeps track
whether the hardware has support for retry mechanism and,
also, if can run multiple requests.
If do_one_request() returns:
>= 0: hardware executed the request successfully;
< 0: this is the old error path. If hardware has support for retry
mechanism, the request is put back in front of crypto-engine queue.
For backwards compatibility, if the retry support is not available,
the crypto-engine will work as before.
If hardware queue is full (-ENOSPC), requeue request regardless
of MAY_BACKLOG flag.
If hardware throws any other error code (like -EIO, -EINVAL,
-ENOMEM, etc.) only MAY_BACKLOG requests are enqueued back into
crypto-engine's queue, since the others can be dropped.
The new crypto_engine_alloc_init_and_set function, initializes
crypto-engine, sets the maximum size for crypto-engine software
queue (not hardcoded anymore) and the retry_support variable
is set, by default, to false.
On crypto_pump_requests(), if do_one_request() returns >= 0,
a new request is send to hardware, until there is no space in
hardware and do_one_request() returns < 0.
By default, retry_support is false and crypto-engine will
work as before - will send requests to hardware,
one-by-one, on crypto_pump_requests(), and complete it, on
crypto_finalize_request(), and so on.
To support multiple requests, in each driver, retry_support
must be set on true, and if do_one_request() returns an error
the request must not be freed, since it will be enqueued back
into crypto-engine's queue.
When all drivers, that use crypto-engine now, will be updated for
retry mechanism, the retry_support variable can be removed.
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-04-28 15:49:04 +00:00
|
|
|
dev_err(engine->dev,
|
|
|
|
"Failed to do one request from queue: %d\n",
|
|
|
|
ret);
|
|
|
|
goto req_err_1;
|
|
|
|
}
|
|
|
|
/*
|
|
|
|
* If retry mechanism is supported,
|
|
|
|
* unprepare current request and
|
|
|
|
* enqueue it back into crypto-engine queue.
|
|
|
|
*/
|
|
|
|
if (enginectx->op.unprepare_request) {
|
|
|
|
ret = enginectx->op.unprepare_request(engine,
|
|
|
|
async_req);
|
|
|
|
if (ret)
|
|
|
|
dev_err(engine->dev,
|
|
|
|
"failed to unprepare request\n");
|
|
|
|
}
|
|
|
|
spin_lock_irqsave(&engine->queue_lock, flags);
|
|
|
|
/*
|
|
|
|
* If hardware was unable to execute request, enqueue it
|
|
|
|
* back in front of crypto-engine queue, to keep the order
|
|
|
|
* of requests.
|
|
|
|
*/
|
|
|
|
crypto_enqueue_request_head(&engine->queue, async_req);
|
|
|
|
|
|
|
|
kthread_queue_work(engine->kworker, &engine->pump_requests);
|
|
|
|
goto out;
|
2018-01-26 19:15:30 +00:00
|
|
|
}
|
2016-01-26 12:25:39 +00:00
|
|
|
|
crypto: engine - support for parallel requests based on retry mechanism
Added support for executing multiple requests, in parallel,
for crypto engine based on a retry mechanism.
If hardware was unable to execute a backlog request, enqueue it
back in front of crypto-engine queue, to keep the order
of requests.
A new variable is added, retry_support (this is to keep the
backward compatibility of crypto-engine) , which keeps track
whether the hardware has support for retry mechanism and,
also, if can run multiple requests.
If do_one_request() returns:
>= 0: hardware executed the request successfully;
< 0: this is the old error path. If hardware has support for retry
mechanism, the request is put back in front of crypto-engine queue.
For backwards compatibility, if the retry support is not available,
the crypto-engine will work as before.
If hardware queue is full (-ENOSPC), requeue request regardless
of MAY_BACKLOG flag.
If hardware throws any other error code (like -EIO, -EINVAL,
-ENOMEM, etc.) only MAY_BACKLOG requests are enqueued back into
crypto-engine's queue, since the others can be dropped.
The new crypto_engine_alloc_init_and_set function, initializes
crypto-engine, sets the maximum size for crypto-engine software
queue (not hardcoded anymore) and the retry_support variable
is set, by default, to false.
On crypto_pump_requests(), if do_one_request() returns >= 0,
a new request is send to hardware, until there is no space in
hardware and do_one_request() returns < 0.
By default, retry_support is false and crypto-engine will
work as before - will send requests to hardware,
one-by-one, on crypto_pump_requests(), and complete it, on
crypto_finalize_request(), and so on.
To support multiple requests, in each driver, retry_support
must be set on true, and if do_one_request() returns an error
the request must not be freed, since it will be enqueued back
into crypto-engine's queue.
When all drivers, that use crypto-engine now, will be updated for
retry mechanism, the retry_support variable can be removed.
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-04-28 15:49:04 +00:00
|
|
|
goto retry;
|
|
|
|
|
|
|
|
req_err_1:
|
|
|
|
if (enginectx->op.unprepare_request) {
|
|
|
|
ret = enginectx->op.unprepare_request(engine, async_req);
|
|
|
|
if (ret)
|
|
|
|
dev_err(engine->dev, "failed to unprepare request\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
req_err_2:
|
|
|
|
async_req->complete(async_req, ret);
|
|
|
|
|
|
|
|
retry:
|
|
|
|
/* If retry mechanism is supported, send new requests to engine */
|
|
|
|
if (engine->retry_support) {
|
|
|
|
spin_lock_irqsave(&engine->queue_lock, flags);
|
|
|
|
goto start_request;
|
|
|
|
}
|
2016-01-26 12:25:39 +00:00
|
|
|
return;
|
|
|
|
|
|
|
|
out:
|
|
|
|
spin_unlock_irqrestore(&engine->queue_lock, flags);
|
2020-04-28 15:49:05 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Batch requests is possible only if
|
|
|
|
* hardware can enqueue multiple requests
|
|
|
|
*/
|
|
|
|
if (engine->do_batch_requests) {
|
|
|
|
ret = engine->do_batch_requests(engine);
|
|
|
|
if (ret)
|
|
|
|
dev_err(engine->dev, "failed to do batch requests: %d\n",
|
|
|
|
ret);
|
|
|
|
}
|
|
|
|
|
crypto: engine - support for parallel requests based on retry mechanism
Added support for executing multiple requests, in parallel,
for crypto engine based on a retry mechanism.
If hardware was unable to execute a backlog request, enqueue it
back in front of crypto-engine queue, to keep the order
of requests.
A new variable is added, retry_support (this is to keep the
backward compatibility of crypto-engine) , which keeps track
whether the hardware has support for retry mechanism and,
also, if can run multiple requests.
If do_one_request() returns:
>= 0: hardware executed the request successfully;
< 0: this is the old error path. If hardware has support for retry
mechanism, the request is put back in front of crypto-engine queue.
For backwards compatibility, if the retry support is not available,
the crypto-engine will work as before.
If hardware queue is full (-ENOSPC), requeue request regardless
of MAY_BACKLOG flag.
If hardware throws any other error code (like -EIO, -EINVAL,
-ENOMEM, etc.) only MAY_BACKLOG requests are enqueued back into
crypto-engine's queue, since the others can be dropped.
The new crypto_engine_alloc_init_and_set function, initializes
crypto-engine, sets the maximum size for crypto-engine software
queue (not hardcoded anymore) and the retry_support variable
is set, by default, to false.
On crypto_pump_requests(), if do_one_request() returns >= 0,
a new request is send to hardware, until there is no space in
hardware and do_one_request() returns < 0.
By default, retry_support is false and crypto-engine will
work as before - will send requests to hardware,
one-by-one, on crypto_pump_requests(), and complete it, on
crypto_finalize_request(), and so on.
To support multiple requests, in each driver, retry_support
must be set on true, and if do_one_request() returns an error
the request must not be freed, since it will be enqueued back
into crypto-engine's queue.
When all drivers, that use crypto-engine now, will be updated for
retry mechanism, the retry_support variable can be removed.
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-04-28 15:49:04 +00:00
|
|
|
return;
|
2016-01-26 12:25:39 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void crypto_pump_work(struct kthread_work *work)
|
|
|
|
{
|
|
|
|
struct crypto_engine *engine =
|
|
|
|
container_of(work, struct crypto_engine, pump_requests);
|
|
|
|
|
|
|
|
crypto_pump_requests(engine, true);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2018-01-26 19:15:30 +00:00
|
|
|
* crypto_transfer_request - transfer the new request into the engine queue
|
2016-01-26 12:25:39 +00:00
|
|
|
* @engine: the hardware engine
|
|
|
|
* @req: the request need to be listed into the engine queue
|
2022-03-16 01:03:01 +00:00
|
|
|
* @need_pump: indicates whether queue the pump of request to kthread_work
|
2016-01-26 12:25:39 +00:00
|
|
|
*/
|
2018-01-26 19:15:30 +00:00
|
|
|
static int crypto_transfer_request(struct crypto_engine *engine,
|
|
|
|
struct crypto_async_request *req,
|
2016-08-31 12:02:58 +00:00
|
|
|
bool need_pump)
|
2016-01-26 12:25:39 +00:00
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
spin_lock_irqsave(&engine->queue_lock, flags);
|
|
|
|
|
|
|
|
if (!engine->running) {
|
|
|
|
spin_unlock_irqrestore(&engine->queue_lock, flags);
|
|
|
|
return -ESHUTDOWN;
|
|
|
|
}
|
|
|
|
|
2018-01-26 19:15:30 +00:00
|
|
|
ret = crypto_enqueue_request(&engine->queue, req);
|
2016-01-26 12:25:39 +00:00
|
|
|
|
|
|
|
if (!engine->busy && need_pump)
|
2016-10-19 11:54:30 +00:00
|
|
|
kthread_queue_work(engine->kworker, &engine->pump_requests);
|
2016-01-26 12:25:39 +00:00
|
|
|
|
|
|
|
spin_unlock_irqrestore(&engine->queue_lock, flags);
|
|
|
|
return ret;
|
|
|
|
}
|
2016-08-31 12:02:58 +00:00
|
|
|
|
|
|
|
/**
|
2018-01-26 19:15:30 +00:00
|
|
|
* crypto_transfer_request_to_engine - transfer one request to list
|
2016-08-31 12:02:58 +00:00
|
|
|
* into the engine queue
|
|
|
|
* @engine: the hardware engine
|
|
|
|
* @req: the request need to be listed into the engine queue
|
|
|
|
*/
|
2018-01-26 19:15:30 +00:00
|
|
|
static int crypto_transfer_request_to_engine(struct crypto_engine *engine,
|
|
|
|
struct crypto_async_request *req)
|
2016-08-31 12:02:58 +00:00
|
|
|
{
|
2018-01-26 19:15:30 +00:00
|
|
|
return crypto_transfer_request(engine, req, true);
|
2016-08-31 12:02:58 +00:00
|
|
|
}
|
|
|
|
|
2018-01-26 19:15:30 +00:00
|
|
|
/**
|
|
|
|
* crypto_transfer_aead_request_to_engine - transfer one aead_request
|
|
|
|
* to list into the engine queue
|
|
|
|
* @engine: the hardware engine
|
|
|
|
* @req: the request need to be listed into the engine queue
|
|
|
|
*/
|
|
|
|
int crypto_transfer_aead_request_to_engine(struct crypto_engine *engine,
|
|
|
|
struct aead_request *req)
|
|
|
|
{
|
|
|
|
return crypto_transfer_request_to_engine(engine, &req->base);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(crypto_transfer_aead_request_to_engine);
|
2016-08-31 12:02:58 +00:00
|
|
|
|
2018-01-26 19:15:30 +00:00
|
|
|
/**
|
|
|
|
* crypto_transfer_akcipher_request_to_engine - transfer one akcipher_request
|
|
|
|
* to list into the engine queue
|
|
|
|
* @engine: the hardware engine
|
|
|
|
* @req: the request need to be listed into the engine queue
|
|
|
|
*/
|
|
|
|
int crypto_transfer_akcipher_request_to_engine(struct crypto_engine *engine,
|
|
|
|
struct akcipher_request *req)
|
|
|
|
{
|
|
|
|
return crypto_transfer_request_to_engine(engine, &req->base);
|
2016-08-31 12:02:58 +00:00
|
|
|
}
|
2018-01-26 19:15:30 +00:00
|
|
|
EXPORT_SYMBOL_GPL(crypto_transfer_akcipher_request_to_engine);
|
2016-01-26 12:25:39 +00:00
|
|
|
|
|
|
|
/**
|
2018-01-26 19:15:30 +00:00
|
|
|
* crypto_transfer_hash_request_to_engine - transfer one ahash_request
|
|
|
|
* to list into the engine queue
|
2016-01-26 12:25:39 +00:00
|
|
|
* @engine: the hardware engine
|
|
|
|
* @req: the request need to be listed into the engine queue
|
|
|
|
*/
|
2016-08-31 12:02:58 +00:00
|
|
|
int crypto_transfer_hash_request_to_engine(struct crypto_engine *engine,
|
|
|
|
struct ahash_request *req)
|
2016-01-26 12:25:39 +00:00
|
|
|
{
|
2018-01-26 19:15:30 +00:00
|
|
|
return crypto_transfer_request_to_engine(engine, &req->base);
|
2016-01-26 12:25:39 +00:00
|
|
|
}
|
2016-08-31 12:02:58 +00:00
|
|
|
EXPORT_SYMBOL_GPL(crypto_transfer_hash_request_to_engine);
|
2016-01-26 12:25:39 +00:00
|
|
|
|
2021-10-20 10:35:34 +00:00
|
|
|
/**
|
|
|
|
* crypto_transfer_kpp_request_to_engine - transfer one kpp_request to list
|
|
|
|
* into the engine queue
|
|
|
|
* @engine: the hardware engine
|
|
|
|
* @req: the request need to be listed into the engine queue
|
|
|
|
*/
|
|
|
|
int crypto_transfer_kpp_request_to_engine(struct crypto_engine *engine,
|
|
|
|
struct kpp_request *req)
|
|
|
|
{
|
|
|
|
return crypto_transfer_request_to_engine(engine, &req->base);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(crypto_transfer_kpp_request_to_engine);
|
|
|
|
|
2016-01-26 12:25:39 +00:00
|
|
|
/**
|
2018-01-26 19:15:30 +00:00
|
|
|
* crypto_transfer_skcipher_request_to_engine - transfer one skcipher_request
|
|
|
|
* to list into the engine queue
|
|
|
|
* @engine: the hardware engine
|
|
|
|
* @req: the request need to be listed into the engine queue
|
|
|
|
*/
|
|
|
|
int crypto_transfer_skcipher_request_to_engine(struct crypto_engine *engine,
|
|
|
|
struct skcipher_request *req)
|
|
|
|
{
|
|
|
|
return crypto_transfer_request_to_engine(engine, &req->base);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(crypto_transfer_skcipher_request_to_engine);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* crypto_finalize_aead_request - finalize one aead_request if
|
|
|
|
* the request is done
|
|
|
|
* @engine: the hardware engine
|
|
|
|
* @req: the request need to be finalized
|
|
|
|
* @err: error number
|
|
|
|
*/
|
|
|
|
void crypto_finalize_aead_request(struct crypto_engine *engine,
|
|
|
|
struct aead_request *req, int err)
|
|
|
|
{
|
|
|
|
return crypto_finalize_request(engine, &req->base, err);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(crypto_finalize_aead_request);
|
2016-01-26 12:25:39 +00:00
|
|
|
|
2018-01-26 19:15:30 +00:00
|
|
|
/**
|
|
|
|
* crypto_finalize_akcipher_request - finalize one akcipher_request if
|
|
|
|
* the request is done
|
|
|
|
* @engine: the hardware engine
|
|
|
|
* @req: the request need to be finalized
|
|
|
|
* @err: error number
|
|
|
|
*/
|
|
|
|
void crypto_finalize_akcipher_request(struct crypto_engine *engine,
|
|
|
|
struct akcipher_request *req, int err)
|
|
|
|
{
|
|
|
|
return crypto_finalize_request(engine, &req->base, err);
|
2016-08-31 12:02:58 +00:00
|
|
|
}
|
2018-01-26 19:15:30 +00:00
|
|
|
EXPORT_SYMBOL_GPL(crypto_finalize_akcipher_request);
|
2016-08-31 12:02:58 +00:00
|
|
|
|
|
|
|
/**
|
2018-01-26 19:15:30 +00:00
|
|
|
* crypto_finalize_hash_request - finalize one ahash_request if
|
|
|
|
* the request is done
|
2016-08-31 12:02:58 +00:00
|
|
|
* @engine: the hardware engine
|
|
|
|
* @req: the request need to be finalized
|
|
|
|
* @err: error number
|
|
|
|
*/
|
|
|
|
void crypto_finalize_hash_request(struct crypto_engine *engine,
|
|
|
|
struct ahash_request *req, int err)
|
|
|
|
{
|
2018-01-26 19:15:30 +00:00
|
|
|
return crypto_finalize_request(engine, &req->base, err);
|
2016-01-26 12:25:39 +00:00
|
|
|
}
|
2016-08-31 12:02:58 +00:00
|
|
|
EXPORT_SYMBOL_GPL(crypto_finalize_hash_request);
|
2016-01-26 12:25:39 +00:00
|
|
|
|
2021-10-20 10:35:34 +00:00
|
|
|
/**
|
|
|
|
* crypto_finalize_kpp_request - finalize one kpp_request if the request is done
|
|
|
|
* @engine: the hardware engine
|
|
|
|
* @req: the request need to be finalized
|
|
|
|
* @err: error number
|
|
|
|
*/
|
|
|
|
void crypto_finalize_kpp_request(struct crypto_engine *engine,
|
|
|
|
struct kpp_request *req, int err)
|
|
|
|
{
|
|
|
|
return crypto_finalize_request(engine, &req->base, err);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(crypto_finalize_kpp_request);
|
|
|
|
|
2018-01-26 19:15:30 +00:00
|
|
|
/**
|
|
|
|
* crypto_finalize_skcipher_request - finalize one skcipher_request if
|
|
|
|
* the request is done
|
|
|
|
* @engine: the hardware engine
|
|
|
|
* @req: the request need to be finalized
|
|
|
|
* @err: error number
|
|
|
|
*/
|
|
|
|
void crypto_finalize_skcipher_request(struct crypto_engine *engine,
|
|
|
|
struct skcipher_request *req, int err)
|
|
|
|
{
|
|
|
|
return crypto_finalize_request(engine, &req->base, err);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(crypto_finalize_skcipher_request);
|
|
|
|
|
2016-01-26 12:25:39 +00:00
|
|
|
/**
|
|
|
|
* crypto_engine_start - start the hardware engine
|
|
|
|
* @engine: the hardware engine need to be started
|
|
|
|
*
|
|
|
|
* Return 0 on success, else on fail.
|
|
|
|
*/
|
|
|
|
int crypto_engine_start(struct crypto_engine *engine)
|
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
spin_lock_irqsave(&engine->queue_lock, flags);
|
|
|
|
|
|
|
|
if (engine->running || engine->busy) {
|
|
|
|
spin_unlock_irqrestore(&engine->queue_lock, flags);
|
|
|
|
return -EBUSY;
|
|
|
|
}
|
|
|
|
|
|
|
|
engine->running = true;
|
|
|
|
spin_unlock_irqrestore(&engine->queue_lock, flags);
|
|
|
|
|
2016-10-19 11:54:30 +00:00
|
|
|
kthread_queue_work(engine->kworker, &engine->pump_requests);
|
2016-01-26 12:25:39 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(crypto_engine_start);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* crypto_engine_stop - stop the hardware engine
|
|
|
|
* @engine: the hardware engine need to be stopped
|
|
|
|
*
|
|
|
|
* Return 0 on success, else on fail.
|
|
|
|
*/
|
|
|
|
int crypto_engine_stop(struct crypto_engine *engine)
|
|
|
|
{
|
|
|
|
unsigned long flags;
|
2016-08-31 12:02:58 +00:00
|
|
|
unsigned int limit = 500;
|
2016-01-26 12:25:39 +00:00
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
spin_lock_irqsave(&engine->queue_lock, flags);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If the engine queue is not empty or the engine is on busy state,
|
|
|
|
* we need to wait for a while to pump the requests of engine queue.
|
|
|
|
*/
|
|
|
|
while ((crypto_queue_len(&engine->queue) || engine->busy) && limit--) {
|
|
|
|
spin_unlock_irqrestore(&engine->queue_lock, flags);
|
|
|
|
msleep(20);
|
|
|
|
spin_lock_irqsave(&engine->queue_lock, flags);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (crypto_queue_len(&engine->queue) || engine->busy)
|
|
|
|
ret = -EBUSY;
|
|
|
|
else
|
|
|
|
engine->running = false;
|
|
|
|
|
|
|
|
spin_unlock_irqrestore(&engine->queue_lock, flags);
|
|
|
|
|
|
|
|
if (ret)
|
2017-06-06 13:44:16 +00:00
|
|
|
dev_warn(engine->dev, "could not stop engine\n");
|
2016-01-26 12:25:39 +00:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(crypto_engine_stop);
|
|
|
|
|
|
|
|
/**
|
crypto: engine - support for parallel requests based on retry mechanism
Added support for executing multiple requests, in parallel,
for crypto engine based on a retry mechanism.
If hardware was unable to execute a backlog request, enqueue it
back in front of crypto-engine queue, to keep the order
of requests.
A new variable is added, retry_support (this is to keep the
backward compatibility of crypto-engine) , which keeps track
whether the hardware has support for retry mechanism and,
also, if can run multiple requests.
If do_one_request() returns:
>= 0: hardware executed the request successfully;
< 0: this is the old error path. If hardware has support for retry
mechanism, the request is put back in front of crypto-engine queue.
For backwards compatibility, if the retry support is not available,
the crypto-engine will work as before.
If hardware queue is full (-ENOSPC), requeue request regardless
of MAY_BACKLOG flag.
If hardware throws any other error code (like -EIO, -EINVAL,
-ENOMEM, etc.) only MAY_BACKLOG requests are enqueued back into
crypto-engine's queue, since the others can be dropped.
The new crypto_engine_alloc_init_and_set function, initializes
crypto-engine, sets the maximum size for crypto-engine software
queue (not hardcoded anymore) and the retry_support variable
is set, by default, to false.
On crypto_pump_requests(), if do_one_request() returns >= 0,
a new request is send to hardware, until there is no space in
hardware and do_one_request() returns < 0.
By default, retry_support is false and crypto-engine will
work as before - will send requests to hardware,
one-by-one, on crypto_pump_requests(), and complete it, on
crypto_finalize_request(), and so on.
To support multiple requests, in each driver, retry_support
must be set on true, and if do_one_request() returns an error
the request must not be freed, since it will be enqueued back
into crypto-engine's queue.
When all drivers, that use crypto-engine now, will be updated for
retry mechanism, the retry_support variable can be removed.
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-04-28 15:49:04 +00:00
|
|
|
* crypto_engine_alloc_init_and_set - allocate crypto hardware engine structure
|
|
|
|
* and initialize it by setting the maximum number of entries in the software
|
|
|
|
* crypto-engine queue.
|
2016-01-26 12:25:39 +00:00
|
|
|
* @dev: the device attached with one hardware engine
|
crypto: engine - support for parallel requests based on retry mechanism
Added support for executing multiple requests, in parallel,
for crypto engine based on a retry mechanism.
If hardware was unable to execute a backlog request, enqueue it
back in front of crypto-engine queue, to keep the order
of requests.
A new variable is added, retry_support (this is to keep the
backward compatibility of crypto-engine) , which keeps track
whether the hardware has support for retry mechanism and,
also, if can run multiple requests.
If do_one_request() returns:
>= 0: hardware executed the request successfully;
< 0: this is the old error path. If hardware has support for retry
mechanism, the request is put back in front of crypto-engine queue.
For backwards compatibility, if the retry support is not available,
the crypto-engine will work as before.
If hardware queue is full (-ENOSPC), requeue request regardless
of MAY_BACKLOG flag.
If hardware throws any other error code (like -EIO, -EINVAL,
-ENOMEM, etc.) only MAY_BACKLOG requests are enqueued back into
crypto-engine's queue, since the others can be dropped.
The new crypto_engine_alloc_init_and_set function, initializes
crypto-engine, sets the maximum size for crypto-engine software
queue (not hardcoded anymore) and the retry_support variable
is set, by default, to false.
On crypto_pump_requests(), if do_one_request() returns >= 0,
a new request is send to hardware, until there is no space in
hardware and do_one_request() returns < 0.
By default, retry_support is false and crypto-engine will
work as before - will send requests to hardware,
one-by-one, on crypto_pump_requests(), and complete it, on
crypto_finalize_request(), and so on.
To support multiple requests, in each driver, retry_support
must be set on true, and if do_one_request() returns an error
the request must not be freed, since it will be enqueued back
into crypto-engine's queue.
When all drivers, that use crypto-engine now, will be updated for
retry mechanism, the retry_support variable can be removed.
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-04-28 15:49:04 +00:00
|
|
|
* @retry_support: whether hardware has support for retry mechanism
|
2020-07-31 02:39:23 +00:00
|
|
|
* @cbk_do_batch: pointer to a callback function to be invoked when executing
|
2020-04-28 15:49:05 +00:00
|
|
|
* a batch of requests.
|
|
|
|
* This has the form:
|
|
|
|
* callback(struct crypto_engine *engine)
|
|
|
|
* where:
|
|
|
|
* @engine: the crypto engine structure.
|
2016-01-26 12:25:39 +00:00
|
|
|
* @rt: whether this queue is set to run as a realtime task
|
crypto: engine - support for parallel requests based on retry mechanism
Added support for executing multiple requests, in parallel,
for crypto engine based on a retry mechanism.
If hardware was unable to execute a backlog request, enqueue it
back in front of crypto-engine queue, to keep the order
of requests.
A new variable is added, retry_support (this is to keep the
backward compatibility of crypto-engine) , which keeps track
whether the hardware has support for retry mechanism and,
also, if can run multiple requests.
If do_one_request() returns:
>= 0: hardware executed the request successfully;
< 0: this is the old error path. If hardware has support for retry
mechanism, the request is put back in front of crypto-engine queue.
For backwards compatibility, if the retry support is not available,
the crypto-engine will work as before.
If hardware queue is full (-ENOSPC), requeue request regardless
of MAY_BACKLOG flag.
If hardware throws any other error code (like -EIO, -EINVAL,
-ENOMEM, etc.) only MAY_BACKLOG requests are enqueued back into
crypto-engine's queue, since the others can be dropped.
The new crypto_engine_alloc_init_and_set function, initializes
crypto-engine, sets the maximum size for crypto-engine software
queue (not hardcoded anymore) and the retry_support variable
is set, by default, to false.
On crypto_pump_requests(), if do_one_request() returns >= 0,
a new request is send to hardware, until there is no space in
hardware and do_one_request() returns < 0.
By default, retry_support is false and crypto-engine will
work as before - will send requests to hardware,
one-by-one, on crypto_pump_requests(), and complete it, on
crypto_finalize_request(), and so on.
To support multiple requests, in each driver, retry_support
must be set on true, and if do_one_request() returns an error
the request must not be freed, since it will be enqueued back
into crypto-engine's queue.
When all drivers, that use crypto-engine now, will be updated for
retry mechanism, the retry_support variable can be removed.
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-04-28 15:49:04 +00:00
|
|
|
* @qlen: maximum size of the crypto-engine queue
|
2016-01-26 12:25:39 +00:00
|
|
|
*
|
|
|
|
* This must be called from context that can sleep.
|
|
|
|
* Return: the crypto engine structure on success, else NULL.
|
|
|
|
*/
|
crypto: engine - support for parallel requests based on retry mechanism
Added support for executing multiple requests, in parallel,
for crypto engine based on a retry mechanism.
If hardware was unable to execute a backlog request, enqueue it
back in front of crypto-engine queue, to keep the order
of requests.
A new variable is added, retry_support (this is to keep the
backward compatibility of crypto-engine) , which keeps track
whether the hardware has support for retry mechanism and,
also, if can run multiple requests.
If do_one_request() returns:
>= 0: hardware executed the request successfully;
< 0: this is the old error path. If hardware has support for retry
mechanism, the request is put back in front of crypto-engine queue.
For backwards compatibility, if the retry support is not available,
the crypto-engine will work as before.
If hardware queue is full (-ENOSPC), requeue request regardless
of MAY_BACKLOG flag.
If hardware throws any other error code (like -EIO, -EINVAL,
-ENOMEM, etc.) only MAY_BACKLOG requests are enqueued back into
crypto-engine's queue, since the others can be dropped.
The new crypto_engine_alloc_init_and_set function, initializes
crypto-engine, sets the maximum size for crypto-engine software
queue (not hardcoded anymore) and the retry_support variable
is set, by default, to false.
On crypto_pump_requests(), if do_one_request() returns >= 0,
a new request is send to hardware, until there is no space in
hardware and do_one_request() returns < 0.
By default, retry_support is false and crypto-engine will
work as before - will send requests to hardware,
one-by-one, on crypto_pump_requests(), and complete it, on
crypto_finalize_request(), and so on.
To support multiple requests, in each driver, retry_support
must be set on true, and if do_one_request() returns an error
the request must not be freed, since it will be enqueued back
into crypto-engine's queue.
When all drivers, that use crypto-engine now, will be updated for
retry mechanism, the retry_support variable can be removed.
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-04-28 15:49:04 +00:00
|
|
|
struct crypto_engine *crypto_engine_alloc_init_and_set(struct device *dev,
|
|
|
|
bool retry_support,
|
2020-04-28 15:49:05 +00:00
|
|
|
int (*cbk_do_batch)(struct crypto_engine *engine),
|
crypto: engine - support for parallel requests based on retry mechanism
Added support for executing multiple requests, in parallel,
for crypto engine based on a retry mechanism.
If hardware was unable to execute a backlog request, enqueue it
back in front of crypto-engine queue, to keep the order
of requests.
A new variable is added, retry_support (this is to keep the
backward compatibility of crypto-engine) , which keeps track
whether the hardware has support for retry mechanism and,
also, if can run multiple requests.
If do_one_request() returns:
>= 0: hardware executed the request successfully;
< 0: this is the old error path. If hardware has support for retry
mechanism, the request is put back in front of crypto-engine queue.
For backwards compatibility, if the retry support is not available,
the crypto-engine will work as before.
If hardware queue is full (-ENOSPC), requeue request regardless
of MAY_BACKLOG flag.
If hardware throws any other error code (like -EIO, -EINVAL,
-ENOMEM, etc.) only MAY_BACKLOG requests are enqueued back into
crypto-engine's queue, since the others can be dropped.
The new crypto_engine_alloc_init_and_set function, initializes
crypto-engine, sets the maximum size for crypto-engine software
queue (not hardcoded anymore) and the retry_support variable
is set, by default, to false.
On crypto_pump_requests(), if do_one_request() returns >= 0,
a new request is send to hardware, until there is no space in
hardware and do_one_request() returns < 0.
By default, retry_support is false and crypto-engine will
work as before - will send requests to hardware,
one-by-one, on crypto_pump_requests(), and complete it, on
crypto_finalize_request(), and so on.
To support multiple requests, in each driver, retry_support
must be set on true, and if do_one_request() returns an error
the request must not be freed, since it will be enqueued back
into crypto-engine's queue.
When all drivers, that use crypto-engine now, will be updated for
retry mechanism, the retry_support variable can be removed.
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-04-28 15:49:04 +00:00
|
|
|
bool rt, int qlen)
|
2016-01-26 12:25:39 +00:00
|
|
|
{
|
|
|
|
struct crypto_engine *engine;
|
|
|
|
|
|
|
|
if (!dev)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
engine = devm_kzalloc(dev, sizeof(*engine), GFP_KERNEL);
|
|
|
|
if (!engine)
|
|
|
|
return NULL;
|
|
|
|
|
2017-06-06 13:44:16 +00:00
|
|
|
engine->dev = dev;
|
2016-01-26 12:25:39 +00:00
|
|
|
engine->rt = rt;
|
|
|
|
engine->running = false;
|
|
|
|
engine->busy = false;
|
|
|
|
engine->idling = false;
|
crypto: engine - support for parallel requests based on retry mechanism
Added support for executing multiple requests, in parallel,
for crypto engine based on a retry mechanism.
If hardware was unable to execute a backlog request, enqueue it
back in front of crypto-engine queue, to keep the order
of requests.
A new variable is added, retry_support (this is to keep the
backward compatibility of crypto-engine) , which keeps track
whether the hardware has support for retry mechanism and,
also, if can run multiple requests.
If do_one_request() returns:
>= 0: hardware executed the request successfully;
< 0: this is the old error path. If hardware has support for retry
mechanism, the request is put back in front of crypto-engine queue.
For backwards compatibility, if the retry support is not available,
the crypto-engine will work as before.
If hardware queue is full (-ENOSPC), requeue request regardless
of MAY_BACKLOG flag.
If hardware throws any other error code (like -EIO, -EINVAL,
-ENOMEM, etc.) only MAY_BACKLOG requests are enqueued back into
crypto-engine's queue, since the others can be dropped.
The new crypto_engine_alloc_init_and_set function, initializes
crypto-engine, sets the maximum size for crypto-engine software
queue (not hardcoded anymore) and the retry_support variable
is set, by default, to false.
On crypto_pump_requests(), if do_one_request() returns >= 0,
a new request is send to hardware, until there is no space in
hardware and do_one_request() returns < 0.
By default, retry_support is false and crypto-engine will
work as before - will send requests to hardware,
one-by-one, on crypto_pump_requests(), and complete it, on
crypto_finalize_request(), and so on.
To support multiple requests, in each driver, retry_support
must be set on true, and if do_one_request() returns an error
the request must not be freed, since it will be enqueued back
into crypto-engine's queue.
When all drivers, that use crypto-engine now, will be updated for
retry mechanism, the retry_support variable can be removed.
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-04-28 15:49:04 +00:00
|
|
|
engine->retry_support = retry_support;
|
2016-01-26 12:25:39 +00:00
|
|
|
engine->priv_data = dev;
|
2020-04-28 15:49:05 +00:00
|
|
|
/*
|
|
|
|
* Batch requests is possible only if
|
|
|
|
* hardware has support for retry mechanism.
|
|
|
|
*/
|
|
|
|
engine->do_batch_requests = retry_support ? cbk_do_batch : NULL;
|
|
|
|
|
2016-01-26 12:25:39 +00:00
|
|
|
snprintf(engine->name, sizeof(engine->name),
|
|
|
|
"%s-engine", dev_name(dev));
|
|
|
|
|
crypto: engine - support for parallel requests based on retry mechanism
Added support for executing multiple requests, in parallel,
for crypto engine based on a retry mechanism.
If hardware was unable to execute a backlog request, enqueue it
back in front of crypto-engine queue, to keep the order
of requests.
A new variable is added, retry_support (this is to keep the
backward compatibility of crypto-engine) , which keeps track
whether the hardware has support for retry mechanism and,
also, if can run multiple requests.
If do_one_request() returns:
>= 0: hardware executed the request successfully;
< 0: this is the old error path. If hardware has support for retry
mechanism, the request is put back in front of crypto-engine queue.
For backwards compatibility, if the retry support is not available,
the crypto-engine will work as before.
If hardware queue is full (-ENOSPC), requeue request regardless
of MAY_BACKLOG flag.
If hardware throws any other error code (like -EIO, -EINVAL,
-ENOMEM, etc.) only MAY_BACKLOG requests are enqueued back into
crypto-engine's queue, since the others can be dropped.
The new crypto_engine_alloc_init_and_set function, initializes
crypto-engine, sets the maximum size for crypto-engine software
queue (not hardcoded anymore) and the retry_support variable
is set, by default, to false.
On crypto_pump_requests(), if do_one_request() returns >= 0,
a new request is send to hardware, until there is no space in
hardware and do_one_request() returns < 0.
By default, retry_support is false and crypto-engine will
work as before - will send requests to hardware,
one-by-one, on crypto_pump_requests(), and complete it, on
crypto_finalize_request(), and so on.
To support multiple requests, in each driver, retry_support
must be set on true, and if do_one_request() returns an error
the request must not be freed, since it will be enqueued back
into crypto-engine's queue.
When all drivers, that use crypto-engine now, will be updated for
retry mechanism, the retry_support variable can be removed.
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-04-28 15:49:04 +00:00
|
|
|
crypto_init_queue(&engine->queue, qlen);
|
2016-01-26 12:25:39 +00:00
|
|
|
spin_lock_init(&engine->queue_lock);
|
|
|
|
|
2016-10-19 11:54:30 +00:00
|
|
|
engine->kworker = kthread_create_worker(0, "%s", engine->name);
|
|
|
|
if (IS_ERR(engine->kworker)) {
|
2016-01-26 12:25:39 +00:00
|
|
|
dev_err(dev, "failed to create crypto request pump task\n");
|
|
|
|
return NULL;
|
|
|
|
}
|
2016-10-11 20:55:20 +00:00
|
|
|
kthread_init_work(&engine->pump_requests, crypto_pump_work);
|
2016-01-26 12:25:39 +00:00
|
|
|
|
|
|
|
if (engine->rt) {
|
|
|
|
dev_info(dev, "will run requests pump with realtime priority\n");
|
2020-04-21 10:09:13 +00:00
|
|
|
sched_set_fifo(engine->kworker->task);
|
2016-01-26 12:25:39 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return engine;
|
|
|
|
}
|
crypto: engine - support for parallel requests based on retry mechanism
Added support for executing multiple requests, in parallel,
for crypto engine based on a retry mechanism.
If hardware was unable to execute a backlog request, enqueue it
back in front of crypto-engine queue, to keep the order
of requests.
A new variable is added, retry_support (this is to keep the
backward compatibility of crypto-engine) , which keeps track
whether the hardware has support for retry mechanism and,
also, if can run multiple requests.
If do_one_request() returns:
>= 0: hardware executed the request successfully;
< 0: this is the old error path. If hardware has support for retry
mechanism, the request is put back in front of crypto-engine queue.
For backwards compatibility, if the retry support is not available,
the crypto-engine will work as before.
If hardware queue is full (-ENOSPC), requeue request regardless
of MAY_BACKLOG flag.
If hardware throws any other error code (like -EIO, -EINVAL,
-ENOMEM, etc.) only MAY_BACKLOG requests are enqueued back into
crypto-engine's queue, since the others can be dropped.
The new crypto_engine_alloc_init_and_set function, initializes
crypto-engine, sets the maximum size for crypto-engine software
queue (not hardcoded anymore) and the retry_support variable
is set, by default, to false.
On crypto_pump_requests(), if do_one_request() returns >= 0,
a new request is send to hardware, until there is no space in
hardware and do_one_request() returns < 0.
By default, retry_support is false and crypto-engine will
work as before - will send requests to hardware,
one-by-one, on crypto_pump_requests(), and complete it, on
crypto_finalize_request(), and so on.
To support multiple requests, in each driver, retry_support
must be set on true, and if do_one_request() returns an error
the request must not be freed, since it will be enqueued back
into crypto-engine's queue.
When all drivers, that use crypto-engine now, will be updated for
retry mechanism, the retry_support variable can be removed.
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-04-28 15:49:04 +00:00
|
|
|
EXPORT_SYMBOL_GPL(crypto_engine_alloc_init_and_set);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* crypto_engine_alloc_init - allocate crypto hardware engine structure and
|
|
|
|
* initialize it.
|
|
|
|
* @dev: the device attached with one hardware engine
|
|
|
|
* @rt: whether this queue is set to run as a realtime task
|
|
|
|
*
|
|
|
|
* This must be called from context that can sleep.
|
|
|
|
* Return: the crypto engine structure on success, else NULL.
|
|
|
|
*/
|
|
|
|
struct crypto_engine *crypto_engine_alloc_init(struct device *dev, bool rt)
|
|
|
|
{
|
2020-04-28 15:49:05 +00:00
|
|
|
return crypto_engine_alloc_init_and_set(dev, false, NULL, rt,
|
crypto: engine - support for parallel requests based on retry mechanism
Added support for executing multiple requests, in parallel,
for crypto engine based on a retry mechanism.
If hardware was unable to execute a backlog request, enqueue it
back in front of crypto-engine queue, to keep the order
of requests.
A new variable is added, retry_support (this is to keep the
backward compatibility of crypto-engine) , which keeps track
whether the hardware has support for retry mechanism and,
also, if can run multiple requests.
If do_one_request() returns:
>= 0: hardware executed the request successfully;
< 0: this is the old error path. If hardware has support for retry
mechanism, the request is put back in front of crypto-engine queue.
For backwards compatibility, if the retry support is not available,
the crypto-engine will work as before.
If hardware queue is full (-ENOSPC), requeue request regardless
of MAY_BACKLOG flag.
If hardware throws any other error code (like -EIO, -EINVAL,
-ENOMEM, etc.) only MAY_BACKLOG requests are enqueued back into
crypto-engine's queue, since the others can be dropped.
The new crypto_engine_alloc_init_and_set function, initializes
crypto-engine, sets the maximum size for crypto-engine software
queue (not hardcoded anymore) and the retry_support variable
is set, by default, to false.
On crypto_pump_requests(), if do_one_request() returns >= 0,
a new request is send to hardware, until there is no space in
hardware and do_one_request() returns < 0.
By default, retry_support is false and crypto-engine will
work as before - will send requests to hardware,
one-by-one, on crypto_pump_requests(), and complete it, on
crypto_finalize_request(), and so on.
To support multiple requests, in each driver, retry_support
must be set on true, and if do_one_request() returns an error
the request must not be freed, since it will be enqueued back
into crypto-engine's queue.
When all drivers, that use crypto-engine now, will be updated for
retry mechanism, the retry_support variable can be removed.
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-04-28 15:49:04 +00:00
|
|
|
CRYPTO_ENGINE_MAX_QLEN);
|
|
|
|
}
|
2016-01-26 12:25:39 +00:00
|
|
|
EXPORT_SYMBOL_GPL(crypto_engine_alloc_init);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* crypto_engine_exit - free the resources of hardware engine when exit
|
|
|
|
* @engine: the hardware engine need to be freed
|
|
|
|
*
|
|
|
|
* Return 0 for success.
|
|
|
|
*/
|
|
|
|
int crypto_engine_exit(struct crypto_engine *engine)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = crypto_engine_stop(engine);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2016-10-19 11:54:30 +00:00
|
|
|
kthread_destroy_worker(engine->kworker);
|
2016-01-26 12:25:39 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(crypto_engine_exit);
|
|
|
|
|
|
|
|
MODULE_LICENSE("GPL");
|
|
|
|
MODULE_DESCRIPTION("Crypto hardware engine framework");
|