RE: [PATCH v7 6/8] fsl-dma: use spin_lock_bh to instead of spin_lock_irqsave

-----Original Message-----
From: dan.j.williams@gmail.com [mailto:dan.j.williams@gmail.com] On
Behalf Of Dan Williams
Sent: Sunday, September 02, 2012 4:41 PM
To: Liu Qiang-B32616
Cc: linux-crypto@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; linux-
kernel@vger.kernel.org; vinod.koul@intel.com; Phillips Kim-R1AAHA;
herbert@gondor.hengli.com.au; davem@davemloft.net; arnd@arndb.de;
gregkh@linuxfoundation.org; Li Yang-R58472; Tabi Timur-B04825
Subject: Re: [PATCH v7 6/8] fsl-dma: use spin_lock_bh to instead of
spin_lock_irqsave

On Thu, Aug 9, 2012 at 1:23 AM,  [off-list ref] wrote:

quoted

From: Qiang Liu <redacted>

The use of spin_lock_irqsave() is a stronger locking mechanism than is
required throughout the driver. The minimum locking required should be
used instead. Interrupts will be turned off and context will be saved,
there is needless to use irqsave.

Change all instances of spin_lock_irqsave() to spin_lock_bh().
All manipulation of protected fields is done using tasklet context or
weaker, which makes spin_lock_bh() the correct choice.

It seems you are coordinating fsl-dma copy and talitos xor operations.
 It looks like fsl-dma will be called through
talitos_process_pending()->dma_run_dependencies(), which is
potentially called in hard irq context.

This all comes back to the need to fix raid offload to manage the
channels explicitly rather than the current dependency chains.

So you mean I must implement talitos_run_dependencies() and fsldma_run_dependencies()? Invoke async_tx->callback() respectively.
How about avoiding irq context in talitos?

--
Dan