summaryrefslogtreecommitdiff
path: root/sound
diff options
context:
space:
mode:
authorHoria Geantă <horia.geanta@nxp.com>2017-02-10 12:07:25 (GMT)
committerXie Xiaobo <xiaobo.xie@nxp.com>2017-09-25 07:25:22 (GMT)
commit758a38cbd2647db2216f709f48450c6aa9e08643 (patch)
tree52551b7b473d8692cfa9832b3e9de61e8e29f6e5 /sound
parentbb7688f1ef15e4afe1149c25f2229be92cb0689d (diff)
downloadlinux-758a38cbd2647db2216f709f48450c6aa9e08643.tar.xz
crypto: caam - fix state buffer DMA (un)mapping
If we register the DMA API debug notification chain to receive platform bus events: dma_debug_add_bus(&platform_bus_type); we start receiving warnings after a simple test like "modprobe caam_jr && modprobe caamhash && modprobe -r caamhash && modprobe -r caam_jr": platform ffe301000.jr: DMA-API: device driver has pending DMA allocations while released from device [count=1938] One of leaked entries details: [device address=0x0000000173fda090] [size=63 bytes] [mapped with DMA_TO_DEVICE] [mapped as single] It turns out there are several issues with handling buf_dma (mapping of buffer holding the previous chunk smaller than hash block size): -detection of buf_dma mapping failure occurs too late, after a job descriptor using that value has been submitted for execution -dma mapping leak - unmapping is not performed in all places: for e.g. in ahash_export or in most ahash_fin* callbacks (due to current back-to-back implementation of buf_dma unmapping/mapping) Fix these by: -calling dma_mapping_error() on buf_dma right after the mapping and providing an error code if needed -unmapping buf_dma during the "job done" (ahash_done_*) callbacks Signed-off-by: Horia Geantă <horia.geanta@nxp.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Diffstat (limited to 'sound')
0 files changed, 0 insertions, 0 deletions