diff options
author | Lars-Peter Clausen <lars@metafoo.de> | 2012-04-25 18:50:52 (GMT) |
---|---|---|
committer | Vinod Koul <vinod.koul@linux.intel.com> | 2012-05-11 06:34:38 (GMT) |
commit | fdaf9c4b22247a6cc6cda9459be3e52764c14d95 (patch) | |
tree | c567736f1f47f91003a658b11075e974cee4321b /include/linux/dmaengine.h | |
parent | cbb796ccd8c33c50249b876d9773dfa8e67d39cb (diff) | |
download | linux-fsl-qoriq-fdaf9c4b22247a6cc6cda9459be3e52764c14d95.tar.xz |
dmaengine: Use dma_sg_len(sg) instead of sg->length
sg->length may or may not contain the length of the dma region to transfer,
depending on the architecture - dma_sg_len(sg) always will though. For the
architectures which use the drivers modified by this patch it probably is the
case that sg->length contains the dma transfer length. But to be consistent and
future proof change them to use dma_sg_len.
To quote Russel King:
sg->length is meaningless to something performing DMA.
In cases where sg_dma_len(sg) and sg->length are the same storage, then
there's no problem. But scatterlists _can_ (and one some architectures) do
split them - especially when you have an IOMMU which can allow you to
combine a scatterlist into fewer entries.
So, anything using sg->length for the size of a scatterlist's DMA transfer
_after_ a call to dma_map_sg() is almost certainly buggy.
The patch has been generated using the following coccinelle patch:
<smpl>
@@
struct scatterlist *sg;
expression X;
@@
-sg[X].length
+sg_dma_len(&sg[X])
@@
struct scatterlist *sg;
@@
-sg->length
+sg_dma_len(sg)
</smpl>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
Diffstat (limited to 'include/linux/dmaengine.h')
0 files changed, 0 insertions, 0 deletions