From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
Lior Amsalem <alior@marvell.com>, Andrew Lunn <andrew@lunn.ch>,
Nadav Haklai <nadavh@marvell.com>,
Mark Rutland <mark.rutland@arm.com>,
Tawfik Bayouk <tawfik@marvell.com>,
Eran Ben-Avi <benavi@marvell.com>,
Jason Gunthorpe <jgunthorpe@obsidianresearch.com>,
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
devicetree@vger.kernel.org, Jason Cooper <jason@lakedaemon.net>,
Pawel Moll <pawel.moll@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Arnaud Ebalard <arno@natisbad.org>,
Rob Herring <robh+dt@kernel.org>,
Gregory CLEMENT <gregory.clement@free-electrons.com>,
linux-arm-kernel@lists.infradead.org,
Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
Kumar Gala <galak@codeaurora.org>, Imre Kaloz <kaloz@openwrt.org>,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH v6 05/14] crypto: marvell/CESA: add TDMA support
Date: Thu, 18 Jun 2015 11:33:24 +0200 [thread overview]
Message-ID: <20150618113324.2d469103@bbrezillon> (raw)
In-Reply-To: <20150618090400.GG7557@n2100.arm.linux.org.uk>
Hi Russel,
On Thu, 18 Jun 2015 10:04:00 +0100
Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> On Wed, Jun 17, 2015 at 05:50:01PM +0800, Herbert Xu wrote:
> > On Wed, Jun 17, 2015 at 09:45:33AM +0200, Boris Brezillon wrote:
> > >
> > > + ret = dma_map_sg(cesa_dev->dev, req->src, creq->src_nents,
> > > + DMA_TO_DEVICE);
> > > + if (!ret)
> > > + return -ENOMEM;
> > > +
> > > + creq->src_nents = ret;
> >
> > DMA-API-HOWTO says that you must retain the original nents and
> > use it when you call dma_unmap_sg. So I'm afraid one more repost
> > is needed :)
>
> It's worse than that... You're right on that point, but there's an
> additional point.
>
> If dma_map_sg() coalesces scatterlist entries, then ret will be smaller
> than src_nents, and ret indicates how many scatterlist entries to be
> walked during DMA - you should not use src_nents for that. I couldn't
> see where the driver used that information. In fact, the driver seems
> to be capable of walking more than src_nents/ret numbers of scatterlist
> entries: it just keeps going with sg_next() until it hits the end of
> the allocated scatterlist.
Yes, I realized that, and I never used the value returned by
dma_map_sg() to walk the scatterlist anyway: I was using the sg_next()
and sg->length value (which I replaced by sg_dma_len() in v7 as
suggested by Herbert).
So the ->src_nents assignment to dma_map_sg() return value was just a
silly mistake caused by an uncareful read of the DMA-API-HOWTO.
Am I missing something else ?
Best Regards,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
WARNING: multiple messages have this Message-ID (diff)
From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
Lior Amsalem <alior@marvell.com>, Andrew Lunn <andrew@lunn.ch>,
Nadav Haklai <nadavh@marvell.com>,
Mark Rutland <mark.rutland@arm.com>,
Tawfik Bayouk <tawfik@marvell.com>,
Eran Ben-Avi <benavi@marvell.com>,
Jason Gunthorpe <jgunthorpe@obsidianresearch.com>,
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
devicetree@vger.kernel.org, Jason Cooper <jason@lakedaemon.net>,
Pawel Moll <pawel.moll@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Arnaud Ebalard <arno@natisbad.org>,
Rob Herring <robh+dt@kernel.org>,
Gregory CLEMENT <gregory.clement@free-electrons.com>,
linux-arm-kernel@lists.infradead.org,
Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
Kumar Gala <galak@codeaurora.org>, Imre Kaloz <kaloz@openwrt.org>,
"David S. Miller" <davem@daveml
Subject: Re: [PATCH v6 05/14] crypto: marvell/CESA: add TDMA support
Date: Thu, 18 Jun 2015 11:33:24 +0200 [thread overview]
Message-ID: <20150618113324.2d469103@bbrezillon> (raw)
In-Reply-To: <20150618090400.GG7557@n2100.arm.linux.org.uk>
Hi Russel,
On Thu, 18 Jun 2015 10:04:00 +0100
Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> On Wed, Jun 17, 2015 at 05:50:01PM +0800, Herbert Xu wrote:
> > On Wed, Jun 17, 2015 at 09:45:33AM +0200, Boris Brezillon wrote:
> > >
> > > + ret = dma_map_sg(cesa_dev->dev, req->src, creq->src_nents,
> > > + DMA_TO_DEVICE);
> > > + if (!ret)
> > > + return -ENOMEM;
> > > +
> > > + creq->src_nents = ret;
> >
> > DMA-API-HOWTO says that you must retain the original nents and
> > use it when you call dma_unmap_sg. So I'm afraid one more repost
> > is needed :)
>
> It's worse than that... You're right on that point, but there's an
> additional point.
>
> If dma_map_sg() coalesces scatterlist entries, then ret will be smaller
> than src_nents, and ret indicates how many scatterlist entries to be
> walked during DMA - you should not use src_nents for that. I couldn't
> see where the driver used that information. In fact, the driver seems
> to be capable of walking more than src_nents/ret numbers of scatterlist
> entries: it just keeps going with sg_next() until it hits the end of
> the allocated scatterlist.
Yes, I realized that, and I never used the value returned by
dma_map_sg() to walk the scatterlist anyway: I was using the sg_next()
and sg->length value (which I replaced by sg_dma_len() in v7 as
suggested by Herbert).
So the ->src_nents assignment to dma_map_sg() return value was just a
silly mistake caused by an uncareful read of the DMA-API-HOWTO.
Am I missing something else ?
Best Regards,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
WARNING: multiple messages have this Message-ID (diff)
From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
Lior Amsalem <alior@marvell.com>, Andrew Lunn <andrew@lunn.ch>,
Nadav Haklai <nadavh@marvell.com>,
Mark Rutland <mark.rutland@arm.com>,
Tawfik Bayouk <tawfik@marvell.com>,
Eran Ben-Avi <benavi@marvell.com>,
Jason Gunthorpe <jgunthorpe@obsidianresearch.com>,
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
devicetree@vger.kernel.org, Jason Cooper <jason@lakedaemon.net>,
Pawel Moll <pawel.moll@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Arnaud Ebalard <arno@natisbad.org>,
Rob Herring <robh+dt@kernel.org>,
Gregory CLEMENT <gregory.clement@free-electrons.com>,
linux-arm-kernel@lists.infradead.org,
Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
Kumar Gala <galak@codeaurora.org>, Imre Kaloz <kaloz@openwrt.org>,
"David S. Miller" <davem@daveml>
Subject: Re: [PATCH v6 05/14] crypto: marvell/CESA: add TDMA support
Date: Thu, 18 Jun 2015 11:33:24 +0200 [thread overview]
Message-ID: <20150618113324.2d469103@bbrezillon> (raw)
In-Reply-To: <20150618090400.GG7557@n2100.arm.linux.org.uk>
Hi Russel,
On Thu, 18 Jun 2015 10:04:00 +0100
Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> On Wed, Jun 17, 2015 at 05:50:01PM +0800, Herbert Xu wrote:
> > On Wed, Jun 17, 2015 at 09:45:33AM +0200, Boris Brezillon wrote:
> > >
> > > + ret = dma_map_sg(cesa_dev->dev, req->src, creq->src_nents,
> > > + DMA_TO_DEVICE);
> > > + if (!ret)
> > > + return -ENOMEM;
> > > +
> > > + creq->src_nents = ret;
> >
> > DMA-API-HOWTO says that you must retain the original nents and
> > use it when you call dma_unmap_sg. So I'm afraid one more repost
> > is needed :)
>
> It's worse than that... You're right on that point, but there's an
> additional point.
>
> If dma_map_sg() coalesces scatterlist entries, then ret will be smaller
> than src_nents, and ret indicates how many scatterlist entries to be
> walked during DMA - you should not use src_nents for that. I couldn't
> see where the driver used that information. In fact, the driver seems
> to be capable of walking more than src_nents/ret numbers of scatterlist
> entries: it just keeps going with sg_next() until it hits the end of
> the allocated scatterlist.
Yes, I realized that, and I never used the value returned by
dma_map_sg() to walk the scatterlist anyway: I was using the sg_next()
and sg->length value (which I replaced by sg_dma_len() in v7 as
suggested by Herbert).
So the ->src_nents assignment to dma_map_sg() return value was just a
silly mistake caused by an uncareful read of the DMA-API-HOWTO.
Am I missing something else ?
Best Regards,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
WARNING: multiple messages have this Message-ID (diff)
From: boris.brezillon@free-electrons.com (Boris Brezillon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v6 05/14] crypto: marvell/CESA: add TDMA support
Date: Thu, 18 Jun 2015 11:33:24 +0200 [thread overview]
Message-ID: <20150618113324.2d469103@bbrezillon> (raw)
In-Reply-To: <20150618090400.GG7557@n2100.arm.linux.org.uk>
Hi Russel,
On Thu, 18 Jun 2015 10:04:00 +0100
Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> On Wed, Jun 17, 2015 at 05:50:01PM +0800, Herbert Xu wrote:
> > On Wed, Jun 17, 2015 at 09:45:33AM +0200, Boris Brezillon wrote:
> > >
> > > + ret = dma_map_sg(cesa_dev->dev, req->src, creq->src_nents,
> > > + DMA_TO_DEVICE);
> > > + if (!ret)
> > > + return -ENOMEM;
> > > +
> > > + creq->src_nents = ret;
> >
> > DMA-API-HOWTO says that you must retain the original nents and
> > use it when you call dma_unmap_sg. So I'm afraid one more repost
> > is needed :)
>
> It's worse than that... You're right on that point, but there's an
> additional point.
>
> If dma_map_sg() coalesces scatterlist entries, then ret will be smaller
> than src_nents, and ret indicates how many scatterlist entries to be
> walked during DMA - you should not use src_nents for that. I couldn't
> see where the driver used that information. In fact, the driver seems
> to be capable of walking more than src_nents/ret numbers of scatterlist
> entries: it just keeps going with sg_next() until it hits the end of
> the allocated scatterlist.
Yes, I realized that, and I never used the value returned by
dma_map_sg() to walk the scatterlist anyway: I was using the sg_next()
and sg->length value (which I replaced by sg_dma_len() in v7 as
suggested by Herbert).
So the ->src_nents assignment to dma_map_sg() return value was just a
silly mistake caused by an uncareful read of the DMA-API-HOWTO.
Am I missing something else ?
Best Regards,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
next prev parent reply other threads:[~2015-06-18 9:33 UTC|newest]
Thread overview: 87+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-17 7:45 [PATCH v6 00/14] crypto: add a new driver for Marvell's CESA Boris Brezillon
2015-06-17 7:45 ` Boris Brezillon
2015-06-17 7:45 ` Boris Brezillon
2015-06-17 7:45 ` [PATCH v6 01/14] crypto: mv_cesa: document the clocks property Boris Brezillon
2015-06-17 7:45 ` Boris Brezillon
2015-06-17 7:45 ` [PATCH v6 02/14] crypto: mv_cesa: use gen_pool to reserve the SRAM memory region Boris Brezillon
2015-06-17 7:45 ` Boris Brezillon
2015-06-17 7:45 ` Boris Brezillon
2015-06-17 7:45 ` [PATCH v6 03/14] crypto: mv_cesa: explicitly define kirkwood and dove compatible strings Boris Brezillon
2015-06-17 7:45 ` Boris Brezillon
2015-06-17 7:45 ` Boris Brezillon
2015-06-17 7:45 ` [PATCH v6 04/14] crypto: add a new driver for Marvell's CESA Boris Brezillon
2015-06-17 7:45 ` Boris Brezillon
2015-06-17 7:45 ` [PATCH v6 05/14] crypto: marvell/CESA: add TDMA support Boris Brezillon
2015-06-17 7:45 ` Boris Brezillon
2015-06-17 9:50 ` Herbert Xu
2015-06-17 9:50 ` Herbert Xu
2015-06-17 11:33 ` Boris Brezillon
2015-06-17 11:33 ` Boris Brezillon
2015-06-17 12:25 ` Herbert Xu
2015-06-17 12:25 ` Herbert Xu
2015-06-17 13:32 ` [PATCH v7 " Boris Brezillon
2015-06-17 13:32 ` Boris Brezillon
2015-06-17 15:08 ` Herbert Xu
2015-06-17 15:08 ` Herbert Xu
2015-06-17 15:34 ` Boris Brezillon
2015-06-17 15:34 ` Boris Brezillon
2015-06-17 15:34 ` Boris Brezillon
2015-06-17 15:58 ` Boris Brezillon
2015-06-17 15:58 ` Boris Brezillon
2015-06-17 15:58 ` Boris Brezillon
2015-06-17 15:58 ` Boris Brezillon
2015-06-18 1:42 ` Herbert Xu
2015-06-18 1:42 ` Herbert Xu
2015-06-18 1:41 ` Herbert Xu
2015-06-18 1:41 ` Herbert Xu
2015-06-18 9:04 ` [PATCH v6 " Russell King - ARM Linux
2015-06-18 9:04 ` Russell King - ARM Linux
2015-06-18 9:04 ` Russell King - ARM Linux
2015-06-18 9:04 ` Russell King - ARM Linux
2015-06-18 9:33 ` Boris Brezillon [this message]
2015-06-18 9:33 ` Boris Brezillon
2015-06-18 9:33 ` Boris Brezillon
2015-06-18 9:33 ` Boris Brezillon
2015-06-18 9:48 ` Russell King - ARM Linux
2015-06-18 9:48 ` Russell King - ARM Linux
2015-06-18 9:48 ` Russell King - ARM Linux
2015-06-18 9:48 ` Russell King - ARM Linux
2015-06-18 9:52 ` Boris Brezillon
2015-06-18 9:52 ` Boris Brezillon
2015-06-18 9:52 ` Boris Brezillon
2015-06-18 9:52 ` Boris Brezillon
2015-06-18 9:37 ` Herbert Xu
2015-06-18 9:37 ` Herbert Xu
2015-06-18 9:37 ` Herbert Xu
2015-06-18 9:37 ` Herbert Xu
2015-06-17 7:45 ` [PATCH v6 06/14] crypto: marvell/CESA: add DES support Boris Brezillon
2015-06-17 7:45 ` Boris Brezillon
2015-06-17 7:45 ` Boris Brezillon
2015-06-18 6:57 ` Boris Brezillon
2015-06-18 6:57 ` Boris Brezillon
2015-06-18 6:57 ` Boris Brezillon
2015-06-18 6:57 ` Boris Brezillon
2015-06-18 7:02 ` Herbert Xu
2015-06-18 7:02 ` Herbert Xu
2015-06-18 7:02 ` Herbert Xu
2015-06-18 7:02 ` Herbert Xu
2015-06-17 7:45 ` [PATCH v6 07/14] crypto: marvell/CESA: add Triple-DES support Boris Brezillon
2015-06-17 7:45 ` Boris Brezillon
2015-06-17 7:45 ` [PATCH v6 08/14] crypto: marvell/CESA: add MD5 support Boris Brezillon
2015-06-17 7:45 ` Boris Brezillon
2015-06-17 7:45 ` Boris Brezillon
2015-06-17 7:45 ` [PATCH v6 09/14] crypto: marvell/CESA: add SHA256 support Boris Brezillon
2015-06-17 7:45 ` Boris Brezillon
2015-06-17 7:45 ` [PATCH v6 10/14] crypto: marvell/CESA: add support for all armada SoCs Boris Brezillon
2015-06-17 7:45 ` Boris Brezillon
2015-06-17 7:45 ` Boris Brezillon
2015-06-17 7:45 ` [PATCH v6 11/14] crypto: marvell/CESA: add allhwsupport module parameter Boris Brezillon
2015-06-17 7:45 ` Boris Brezillon
2015-06-17 7:45 ` Boris Brezillon
2015-06-17 7:45 ` [PATCH v6 12/14] crypto: marvell/CESA: add support for Orion SoCs Boris Brezillon
2015-06-17 7:45 ` Boris Brezillon
2015-06-17 7:45 ` [PATCH v6 13/14] crypto: marvell/CESA: add support for Kirkwood and Dove SoCs Boris Brezillon
2015-06-17 7:45 ` Boris Brezillon
2015-06-17 7:45 ` [PATCH v6 14/14] crypto: marvell/CESA: add DT bindings documentation Boris Brezillon
2015-06-17 7:45 ` Boris Brezillon
2015-06-17 7:45 ` Boris Brezillon
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=20150618113324.2d469103@bbrezillon \
--to=boris.brezillon@free-electrons.com \
--cc=alior@marvell.com \
--cc=andrew@lunn.ch \
--cc=arno@natisbad.org \
--cc=benavi@marvell.com \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=gregory.clement@free-electrons.com \
--cc=herbert@gondor.apana.org.au \
--cc=ijc+devicetree@hellion.org.uk \
--cc=jason@lakedaemon.net \
--cc=jgunthorpe@obsidianresearch.com \
--cc=kaloz@openwrt.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=mark.rutland@arm.com \
--cc=nadavh@marvell.com \
--cc=pawel.moll@arm.com \
--cc=robh+dt@kernel.org \
--cc=sebastian.hesselbarth@gmail.com \
--cc=tawfik@marvell.com \
--cc=thomas.petazzoni@free-electrons.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.