> On Mon, Dec 14, 2009 at 6:33 AM, Vishnu Suresh <Vishnu@xxxxxxxxxxxxx> wrote:
> > The async_tx descriptors contains dangling pointers.
> > Hence, re-initialize them to NULL before use.
> >
> > Signed-off-by: Vishnu Suresh <Vishnu@xxxxxxxxxxxxx>
> > ---
> > 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?