From: Joel A Fernandes <[email protected]>
Not doing so could cause sleep in interrupt context resulting in a kernel panic.
Tested on an AM33xx SoC device (beaglebone board).
To reproduce the problem, I used the tcrypt kernel module as:
modprobe tcrypt sec=2 mode=403
Signed-off-by: Joel A Fernandes <[email protected]>
Cc: Herbert Xu <[email protected]>
Cc: David S. Miller <[email protected]>
Cc: Mark A. Greer <[email protected]>
---
drivers/crypto/omap-sham.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index edff981..b8bb583 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -923,7 +923,7 @@ static void omap_sham_finish_req(struct ahash_request *req, int err)
dd->flags &= ~(BIT(FLAGS_BUSY) | BIT(FLAGS_FINAL) | BIT(FLAGS_CPU) |
BIT(FLAGS_DMA_READY) | BIT(FLAGS_OUTPUT_READY));
- pm_runtime_put_sync(dd->dev);
+ pm_runtime_put(dd->dev);
if (req->base.complete)
req->base.complete(&req->base, err);
--
1.7.4.1
From: Joel A Fernandes <[email protected]>
Not doing so could cause sleep in interrupt context resulting in a kernel panic.
Tested on an AM33xx SoC device (beaglebone board).
To reproduce the problem, I used the tcrypt kernel module as:
modprobe tcrypt sec=2 mode=500
Signed-off-by: Joel A Fernandes <[email protected]>
Cc: Herbert Xu <[email protected]>
Cc: David S. Miller <[email protected]>
Cc: Mark A. Greer <[email protected]>
---
drivers/crypto/omap-aes.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index cf57866..8450bfd2 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -636,7 +636,7 @@ static void omap_aes_finish_req(struct omap_aes_dev *dd, int err)
pr_debug("err: %d\n", err);
- pm_runtime_put_sync(dd->dev);
+ pm_runtime_put(dd->dev);
dd->flags &= ~FLAGS_BUSY;
req->base.complete(&req->base, err);
--
1.7.4.1
On Fri, Feb 15, 2013 at 01:59:27AM -0600, Joel A Fernandes wrote:
> From: Joel A Fernandes <[email protected]>
Hi Joel.
> Not doing so could cause sleep in interrupt context resulting in a kernel panic.
>
> Tested on an AM33xx SoC device (beaglebone board).
>
> To reproduce the problem, I used the tcrypt kernel module as:
> modprobe tcrypt sec=2 mode=403
>
> Signed-off-by: Joel A Fernandes <[email protected]>
> Cc: Herbert Xu <[email protected]>
> Cc: David S. Miller <[email protected]>
> Cc: Mark A. Greer <[email protected]>
> ---
> drivers/crypto/omap-sham.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
> index edff981..b8bb583 100644
> --- a/drivers/crypto/omap-sham.c
> +++ b/drivers/crypto/omap-sham.c
> @@ -923,7 +923,7 @@ static void omap_sham_finish_req(struct ahash_request *req, int err)
> dd->flags &= ~(BIT(FLAGS_BUSY) | BIT(FLAGS_FINAL) | BIT(FLAGS_CPU) |
> BIT(FLAGS_DMA_READY) | BIT(FLAGS_OUTPUT_READY));
>
> - pm_runtime_put_sync(dd->dev);
> + pm_runtime_put(dd->dev);
>
> if (req->base.complete)
> req->base.complete(&req->base, err);
I like your patch but I think it could use a better description.
Please put in a good description of the symptom(s) you saw,
the root cause, and what you did to fix it (and why it fixes it).
Ditto for the omap-aes patch.
Mark
--