On Mon, Dec 14, 2009 at 6:33 AM, Vishnu Suresh [off-list ref] wrote:

quoted

The async_tx descriptors contains dangling pointers.
Hence, re-initialize them to NULL before use.

Signed-off-by: Vishnu Suresh <redacted>
---
o. Rebased to linux-next as of 20091214

 drivers/crypto/talitos.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 87f06be..9e261c6 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c

@@ -952,6 +952,9 @@ static struct dma_async_tx_descriptor * talitos_prep_dma_xor(
               return NULL;
       }
       dma_async_tx_descriptor_init(&new->async_tx, &xor_chan->common);
+       new->async_tx.parent = NULL;
+       new->async_tx.next = NULL;
+

       desc = &new->hwdesc;
       /* Set destination: Last pointer pair */

These two values are owned by the async_tx api, drivers are not
supposed to touch them.

I have sent this patch and the similar one for fsldma seperately, 
so that if the changes are needed and can be done in dma_async_tx_descriptor_init(), 
these patches can be ignored.  

Both iop_adma and the new ppx4xx driver
(which use the async_tx channel switching capability) get away without
touching these fields which makes me suspect there is a
misunderstanding/bug somewhere else in the talitos implementation.

This bug does not occur on all the platforms. The occurrance is random. 
This occurs when a channel switch between two different devices are present. 
This same initialization is required in case of fsldma as well. 
In case of fsldma/talitosXOR, there are two DMA channels (on same device) and single XOR channel (on another device). 

When used without fsldma, this driver works fine.
Does iop_adma and ppx4xx work in similar enviroment?

quoted

Also that dma_async_tx_descriptor_init() is unexpected in the hot
path, it's only needed at initial descriptor allocation.  End result I
think this driver needs some more time to brew.

--
Dan