summaryrefslogtreecommitdiff
path: root/include/linux/dmaengine.h
diff options
context:
space:
mode:
authorLars-Peter Clausen <lars@metafoo.de>2012-04-25 20:50:52 +0200
committerVinod Koul <vinod.koul@linux.intel.com>2012-05-11 12:04:38 +0530
commitfdaf9c4b22247a6cc6cda9459be3e52764c14d95 (patch)
treec567736f1f47f91003a658b11075e974cee4321b /include/linux/dmaengine.h
parentcbb796ccd8c33c50249b876d9773dfa8e67d39cb (diff)
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