From: Horia Geanta <horia.geanta@nxp.com>
To: Leonard Crestez <leonard.crestez@nxp.com>,
Andrey Smirnov <andrew.smirnov@gmail.com>
Cc: "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
Chris Spencer <christopher.spencer@sea.co.uk>,
Cory Tusar <cory.tusar@zii.aero>, Chris Healy <cphealy@gmail.com>,
Lucas Stach <l.stach@pengutronix.de>,
Aymen Sghaier <aymen.sghaier@nxp.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 03/16] crypto: caam - move tasklet_init() call down
Date: Fri, 5 Jul 2019 10:33:19 +0000 [thread overview]
Message-ID: <VI1PR0402MB34855EFBC80E4EF8A543231998F50@VI1PR0402MB3485.eurprd04.prod.outlook.com> (raw)
In-Reply-To: DB7PR04MB50517E97A2BE28050E056B90EEFB0@DB7PR04MB5051.eurprd04.prod.outlook.com
On 7/4/2019 2:45 AM, Leonard Crestez wrote:
> On 7/3/2019 8:14 PM, Andrey Smirnov wrote:
>> On Wed, Jul 3, 2019 at 6:51 AM Leonard Crestez <leonard.crestez@nxp.com> wrote:
>>> 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.
>>>
Actually there is a previous report (in i.MX BSP) of CAAM job ring generating
an interrupt at probe time, between request_irq() and reset:
https://source.codeaurora.org/external/imx/linux-imx/commit/drivers/crypto/caam?h=imx_4.14.98_2.0.0_ga&id=aa7b3f51971ec1f60f41fe8ea71870b215376b8a
So yes, there might be cases when interrupts are pending.
>>
>> Said tasklet will use both jrp->outring and jrp->entinfo array
>> initialized after IRQ request call in both versions of the code
>> (before/after this patch). AFAICT, the only case where this patch
>> would change initialization safety of the original code is if JR was
>> scheduled somehow while ORSFx is 0 (no jobs done), which I don't think
>> is possible.
>
> I took a second look at caam_jr_init and there is apparently a whole
> bunch of other reset/init stuff done after request_irq. For example
> caam_reset_hw_jr is done after request_irq and masks interrupts?
>
> What I'd expect is that request_irq is done last after all other
> initialization is performed. But I'm not familiar with how CAAM JRs work
> so feel free to ignore this.
>
There's some history here... (which is in contradiction with above-mentioned
report).
Commit 9620fd959fb1 ("crypto: caam - handle interrupt lines shared across rings")
moved request_irq() before JR reset:
"
- resetting a job ring triggers an interrupt, so move request_irq
prior to jr_reset to avoid 'got IRQ but nobody cared' messages.
"
but IIUC that ("resetting a job ring triggers an interrupt") was actually
due to disabling the IRQ line using disable_irq() instead of masking
the interrupt in HW using JRCFGR_LS[IMSK].
The way JR reset sequence is implemented now - in caam_reset_hw_jr() - should not
trigger any interrupt.
Thus, it should be safe to move request_irq() after everything is set up,
at the end of probing.
My suggestion is to move both tasklet_init() and request_irq() at the bottom
of the probe callback.
However, I'd say this is a fix that should be marked accordingly and
should be posted either separately, or at the top of the patch set.
Thanks,
Horia
next prev parent reply other threads:[~2019-07-05 10:33 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-03 8:13 [PATCH v4 00/16] crypto: caam - Add i.MX8MQ support Andrey Smirnov
2019-07-03 8:13 ` [PATCH v4 01/16] crypto: caam - move DMA mask selection into a function Andrey Smirnov
2019-07-03 8:13 ` [PATCH v4 02/16] crypto: caam - simplify clock initialization Andrey Smirnov
2019-07-03 13:54 ` Leonard Crestez
2019-07-04 15:43 ` Iuliana Prodan
2019-07-15 18:14 ` Andrey Smirnov
2019-07-03 8:13 ` [PATCH v4 03/16] crypto: caam - move tasklet_init() call down Andrey Smirnov
2019-07-03 13:51 ` Leonard Crestez
2019-07-03 17:14 ` Andrey Smirnov
2019-07-03 23:45 ` Leonard Crestez
2019-07-05 10:33 ` Horia Geanta [this message]
2019-07-03 8:13 ` [PATCH v4 04/16] crypto: caam - use deveres to allocate 'entinfo' Andrey Smirnov
2019-07-03 8:13 ` [PATCH v4 05/16] crypto: caam - use devres to allocate 'outring' Andrey Smirnov
2019-07-04 9:54 ` Horia Geanta
2019-07-03 8:13 ` [PATCH v4 06/16] crypto: caam - use devres to allocate 'inpring' Andrey Smirnov
2019-07-03 8:13 ` [PATCH v4 07/16] crytpo: caam - make use of iowrite64*_hi_lo in wr_reg64 Andrey Smirnov
2019-07-03 8:13 ` [PATCH v4 08/16] crypto: caam - use ioread64*_hi_lo in rd_reg64 Andrey Smirnov
2019-07-03 8:13 ` [PATCH v4 09/16] crypto: caam - drop 64-bit only wr/rd_reg64() Andrey Smirnov
2019-07-03 8:13 ` [PATCH v4 10/16] crypto: caam - make CAAM_PTR_SZ dynamic Andrey Smirnov
2019-07-03 8:13 ` [PATCH v4 11/16] crypto: caam - move cpu_to_caam_dma() selection to runtime Andrey Smirnov
2019-07-03 8:13 ` [PATCH v4 12/16] crypto: caam - drop explicit usage of struct jr_outentry Andrey Smirnov
2019-07-03 8:13 ` [PATCH v4 13/16] crypto: caam - don't hardcode inpentry size Andrey Smirnov
2019-07-03 8:13 ` [PATCH v4 14/16] crypto: caam - force DMA address to 32-bit on 64-bit i.MX SoCs Andrey Smirnov
2019-07-03 8:13 ` [PATCH v4 15/16] crypto: caam - always select job ring via RSR on i.MX8MQ Andrey Smirnov
2019-07-03 8:13 ` [PATCH v4 16/16] crypto: caam - add clock entry for i.MX8MQ Andrey Smirnov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=VI1PR0402MB34855EFBC80E4EF8A543231998F50@VI1PR0402MB3485.eurprd04.prod.outlook.com \
--to=horia.geanta@nxp.com \
--cc=andrew.smirnov@gmail.com \
--cc=aymen.sghaier@nxp.com \
--cc=christopher.spencer@sea.co.uk \
--cc=cory.tusar@zii.aero \
--cc=cphealy@gmail.com \
--cc=l.stach@pengutronix.de \
--cc=leonard.crestez@nxp.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).