On Wed, 17 Jun 2015 15:18:29 +0800
Herbert Xu wrote:
> On Wed, Jun 17, 2015 at 09:15:03AM +0200, Boris Brezillon wrote:
> >
> > Anyway, now I'm doing the following test:
> >
> > if (creq->src_nents && !ret)
> > return -ENOMEM;
>
> Best not call dma_map_sg at all in the !src_nents case as I
On Wed, Jun 17, 2015 at 09:15:03AM +0200, Boris Brezillon wrote:
>
> Anyway, now I'm doing the following test:
>
> if (creq->src_nents && !ret)
> return -ENOMEM;
Best not call dma_map_sg at all in the !src_nents case as I think
some architectures will WARN or BUG if you give it a zero-lengt
On Wed, 17 Jun 2015 13:56:33 +0800
Herbert Xu wrote:
> On Wed, Jun 17, 2015 at 01:05:27PM +0800, Herbert Xu wrote:
> > On Tue, Jun 16, 2015 at 11:58:59AM +0200, Boris Brezillon wrote:
> > >
> > > + ret = dma_map_sg(cesa_dev->dev, req->src, creq->src_nents,
> > > + DMA_TO_DEVICE);
On Wed, Jun 17, 2015 at 01:05:27PM +0800, Herbert Xu wrote:
> On Tue, Jun 16, 2015 at 11:58:59AM +0200, Boris Brezillon wrote:
> >
> > + ret = dma_map_sg(cesa_dev->dev, req->src, creq->src_nents,
> > +DMA_TO_DEVICE);
> > + if (ret != creq->src_nents)
> > + return -
On Tue, Jun 16, 2015 at 11:58:59AM +0200, Boris Brezillon wrote:
>
> + ret = dma_map_sg(cesa_dev->dev, req->src, creq->src_nents,
> + DMA_TO_DEVICE);
> + if (ret != creq->src_nents)
> + return -ENOMEM;
Hmm it doesn't quite work like that. It returns zero o
The CESA IP supports CPU offload through a dedicated DMA engine (TDMA)
which can control the crypto block.
When you use this mode, all the required data (operation metadata and
payload data) are transferred using DMA, and the results are retrieved
through DMA when possible (hash results are not ret