dmaengine: Stricter legacy checking in dma_request_slave_channel_compat()
authorGeert Uytterhoeven <geert+renesas@glider.be>
Mon, 17 Aug 2015 13:08:55 +0000 (15:08 +0200)
committerVinod Koul <vinod.koul@intel.com>
Thu, 20 Aug 2015 06:31:03 +0000 (12:01 +0530)
commit7dfffb9541bca80bbf8df1869564f9220ee150d2
tree1058e2b57746c9927af77bf7b9e4c240c37caeab
parent89079493437701551938652003eb75b328425c66
dmaengine: Stricter legacy checking in dma_request_slave_channel_compat()

dma_request_slave_channel_compat() is meant for drivers that support
both DT and legacy platform device based probing: if DT channel DMA
setup fails, it will fall back to platform data based DMA channel setup,
using hardcoded DMA channel IDs and a filter function.

However, if the DTS doesn't provide a "dmas" property for the device,
the fallback is also used. If the legacy filter function is not
hardcoded in the DMA slave driver, but comes from platform data, it will
be NULL. Then dma_request_slave_channel_compat() will succeed
incorrectly, and return a DMA channel, as a NULL legacy filter function
actually means "all channels are OK", not "do not match".

Later, when trying to use that DMA channel, it will fail with:

    rcar-dmac e6700000.dma-controller: rcar_dmac_prep_slave_sg: bad parameter: len=1, id=-22

To fix this, ensure that both the filter function and the DMA channel ID
are not NULL before using the legacy fallback.

Note that some DMA slave drivers can handle this failure, and will fall
back to PIO.

See also commit 056f6c87028544de ("dmaengine: shdma: Make dummy
shdma_chan_filter() always return false"), which fixed the same issue
for the case where shdma_chan_filter() is hardcoded in a DMA slave
driver.

Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
include/linux/dmaengine.h