On 7/3/2019 11:14 AM, Andrey Smirnov wrote:
> Move tasklet_init() call further down in order to simplify error path
> cleanup. No functional change intended.
>
> diff --git a/drivers/crypto/caam/jr.c b/drivers/crypto/caam/jr.c
> index 4b25b2fa3d02..a7ca2bbe243f 100644
> --- a/drivers/crypto/caam/jr.c
> +++ b/drivers/crypto/caam/jr.c
> @@ -441,15 +441,13 @@ static int caam_jr_init(struct device *dev)
>
> jrp = dev_get_drvdata(dev);
>
> - tasklet_init(&jrp->irqtask, caam_jr_dequeue, (unsigned long)dev);
> -
> /* Connect job ring interrupt handler. */
> error = request_irq(jrp->irq, caam_jr_interrupt, IRQF_SHARED,
> dev_name(dev), dev);
> if (error) {
> dev_err(dev, "can't connect JobR %d interrupt (%d)\n",
> jrp->ridx, jrp->irq);
> - goto out_kill_deq;
> + return error;
> }
The caam_jr_interrupt handler can schedule the tasklet so it makes sense
to have it be initialized ahead of request_irq. In theory it's possible
for an interrupt to be triggered immediately when request_irq is called.
I'm not very familiar with the CAAM ip, can you ensure no interrupts are
pending in HW at probe time? The "no functional change" part is not obvious.
--
Regards,
Leonard
