BMC/Intel-BMC/linux.git/drivers/dma, branch dev-5.1

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 152

2019-07-02T05:03:44+00:00

Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 3029 file(s). Signed-off-by: Thomas Gleixner Reviewed-by: Allison Randal Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de Signed-off-by: Greg Kroah-Hartman (cherry picked from commit 2874c5fd284268364ece81a7bd936f3c8168e567) Signed-off-by: Joel Stanley

dmaengine: sprd: Fix the right place to configure 2-stage transfer

2019-06-25T03:34:48+00:00

[ Upstream commit c434e377dad1dec05cad1870ce21bc539e1e024f ] Move the 2-stage configuration before configuring the link-list mode, since we will use some 2-stage configuration to fill the link-list configuration. Signed-off-by: Eric Long Signed-off-by: Baolin Wang Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin

dmaengine: sprd: Fix block length overflow

2019-06-25T03:34:48+00:00

[ Upstream commit 89d03b3c126d683f7b2cd5b07178493993d12448 ] The maximum value of block length is 0xffff, so if the configured transfer length is more than 0xffff, that will cause block length overflow to lead a configuration error. Thus we can set block length as the maximum burst length to avoid this issue, since the maximum burst length will not be a big value which is more than 0xffff. Signed-off-by: Eric Long Signed-off-by: Baolin Wang Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin

dmaengine: sprd: Fix the incorrect start for 2-stage destination channels

2019-06-25T03:34:48+00:00

[ Upstream commit 3d626a97f0303e9c30d063434b749de3f0f91fb5 ] The 2-stage destination channel will be triggered by source channel automatically, which means we should not trigger it by software request. Signed-off-by: Eric Long Signed-off-by: Baolin Wang Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin

dmaengine: sprd: Add validation of current descriptor in irq handler

2019-06-25T03:34:48+00:00

[ Upstream commit 58152b0e573e5581c4b9ef7cf06d2e9fafae27d4 ] When user terminates one DMA channel to free all its descriptors, but at the same time one transaction interrupt was triggered possibly, now we should not handle this interrupt by validating if the 'schan->cur_desc' was set as NULL to avoid crashing the kernel. Signed-off-by: Baolin Wang Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin

dmaengine: sprd: Fix the possible crash when getting descriptor status

2019-06-25T03:34:48+00:00

[ Upstream commit 16d0f85e45b99411ac10cb12cdd9279204a72381 ] We will get a NULL virtual descriptor by vchan_find_desc() when the descriptor has been submitted, that will crash the kernel when getting the descriptor status. In this case, since the descriptor has been submitted to process, but it is not completed now, which means the descriptor is listed into the 'vc->desc_submitted' list now. So we can not get current processing descriptor by vchan_find_desc(), but the pointer 'schan->cur_desc' will point to the current processing descriptor, then we can use 'schan->cur_desc' to get current processing descriptor's status to avoid this issue. Signed-off-by: Baolin Wang Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin

dmaengine: mediatek-cqdma: sleeping in atomic context

2019-06-25T03:34:47+00:00

[ Upstream commit 069b3c4214f27b130d0642f32438560db30f452e ] The mtk_cqdma_poll_engine_done() function takes a true/false parameter where true means it's called from atomic context. There are a couple places where it was set to false but it's actually in atomic context so it should be true. All the callers for mtk_cqdma_hard_reset() are holding a spin_lock and in mtk_cqdma_free_chan_resources() we take a spin_lock before calling the mtk_cqdma_poll_engine_done() function. Fixes: b1f01e48df5a ("dmaengine: mediatek: Add MediaTek Command-Queue DMA controller for MT6765 SoC") Signed-off-by: Dan Carpenter Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin

dmaengine: dw-axi-dmac: fix null dereference when pointer first is null

2019-06-25T03:34:47+00:00

[ Upstream commit 0788611c9a0925c607de536b2449de5ed98ef8df ] In the unlikely event that axi_desc_get returns a null desc in the very first iteration of the while-loop the error exit path ends up calling axi_desc_put on a null pointer 'first' and this causes a null pointer dereference. Fix this by adding a null check on pointer 'first' before calling axi_desc_put. Addresses-Coverity: ("Explicit null dereference") Fixes: 1fe20f1b8454 ("dmaengine: Introduce DW AXI DMAC driver") Signed-off-by: Colin Ian King Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin

dmaengine: jz4780: Fix transfers being ACKed too soon

2019-06-25T03:34:47+00:00

[ Upstream commit 4e4106f5e942bff65548e82fc330d40385c89220 ] When a multi-descriptor DMA transfer is in progress, the "IRQ pending" flag will apparently be set for that channel as soon as the last descriptor loads, way before the IRQ actually happens. This behaviour has been observed on the JZ4725B, but maybe other SoCs are affected. In the case where another DMA transfer is running into completion on a separate channel, the IRQ handler would then run the completion handler for our previous channel even if the transfer didn't actually finish. Fix this by checking in the completion handler that we're indeed done; if not the interrupted DMA transfer will simply be resumed. Signed-off-by: Paul Cercueil Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin

dmaengine: idma64: Use actual device for DMA transfers

2019-06-15T09:53:05+00:00

[ Upstream commit 5ba846b1ee0792f5a596b9b0b86d6e8cdebfab06 ] Intel IOMMU, when enabled, tries to find the domain of the device, assuming it's a PCI one, during DMA operations, such as mapping or unmapping. Since we are splitting the actual PCI device to couple of children via MFD framework (see drivers/mfd/intel-lpss.c for details), the DMA device appears to be a platform one, and thus not an actual one that performs DMA. In a such situation IOMMU can't find or allocate a proper domain for its operations. As a result, all DMA operations are failed. In order to fix this, supply parent of the platform device to the DMA engine framework and fix filter functions accordingly. We may rely on the fact that parent is a real PCI device, because no other configuration is present in the wild. Signed-off-by: Andy Shevchenko Acked-by: Mark Brown Acked-by: Greg Kroah-Hartman [for tty parts] Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin