kernel/linux.git/drivers/dma/at_hdmac.c, branch linux-4.16.y

dmaengine: at_hdmac: fix potential NULL pointer dereference in atc_prep_dma_interleaved

2017-11-29T14:18:17+00:00

_xt_ is being dereferenced before it is null checked, hence there is a potential null pointer dereference. Fix this by moving the pointer dereference after _xt_ has been null checked. This issue was detected with the help of Coccinelle. Fixes: 4483320e241c ("dmaengine: Use Pointer xt after NULL check.") Signed-off-by: Gustavo A. R. Silva Acked-by: Ludovic Desroches Signed-off-by: Vinod Koul

dmaengine: remove DMA_SG as it is dead code in kernel

2017-08-22T03:52:11+00:00

There are no in kernel consumers for DMA_SG op. Removing operation, dead code, and test code in dmatest. Signed-off-by: Dave Jiang Reviewed-by: Linus Walleij Cc: Gary Hook Cc: Ludovic Desroches Cc: Kedareswara rao Appana Cc: Li Yang Cc: Michal Simek Signed-off-by: Vinod Koul

dmaengine: at_hdmac: move to dma_pool_zalloc

2016-12-08T15:54:17+00:00

Replace dma_pool_alloc & memset with dma_pool_zalloc. Signed-off-by: Vinod Koul

dmaengine: at_hdmac: convert callback to helper function

2016-08-08T02:41:38+00:00

This is in preperation of moving to a callback that provides results to the callback for the transaction. The conversion will maintain current behavior and the driver must convert to new callback mechanism at a later time in order to receive results. Signed-off-by: Dave Jiang Reviewed-by: Lars-Peter Clausen Cc: Nicolas Ferre Signed-off-by: Vinod Koul

dmaengine: at_hdmac: use %pad format string for dma_addr_t

2015-11-16T03:51:05+00:00

dma_addr_t may be defined as 32 or 64 bit depending on configuration, so it cannot be printed using the normal format strings, as gcc correctly warns: drivers/dma/at_hdmac.c: In function 'atc_prep_dma_interleaved': drivers/dma/at_hdmac.c:731:28: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'dma_addr_t {aka long long unsigned int}' [-Wformat=] This changes the format strings to use the special "%pad" format string that prints a dma_addr_t, and changes the arguments so we pass the address by reference as required. Signed-off-by: Arnd Bergmann Acked-by: Nicolas Ferre Signed-off-by: Vinod Koul

dmaengine: hdmac: Add scatter-gathered memset support

2015-10-29T01:41:16+00:00

Just like memset support, the HDMAC might be used to do a memset over a discontiguous memory area. In such a case, we'll just build up a chain of memset descriptors over the contiguous chunks of memory to set, in order to allow such a support. Signed-off-by: Maxime Ripard Acked-by: Nicolas Ferre Signed-off-by: Vinod Koul

dmaengine: hdmac: factorise memset descriptor allocation

2015-10-29T01:40:09+00:00

The memset and scatter gathered memset are going to use some common logic to create their descriptors. Move that logic into a function of its own so that we can share it with the future memset_sg callback. Signed-off-by: Maxime Ripard Acked-by: Nicolas Ferre Signed-off-by: Vinod Koul

Merge tag 'dmaengine-4.3-rc1' of git://git.infradead.org/users/vkoul/slave-dma

2015-09-04T18:10:18+00:00

Pull dmaengine updates from Vinod Koul: "This time we have aded a new capability for scatter-gathered memset using dmaengine APIs. This is supported in xdmac & hdmac drivers We have added support for reusing descriptors for examples like video buffers etc. Driver will follow The behaviour of descriptor ack has been clarified and documented New devices added are: - dma controller in sun[457]i SoCs - lpc18xx dmamux - ZTE ZX296702 dma controller - Analog Devices AXI-DMAC DMA controller - eDMA support for dma-crossbar - imx6sx support in imx-sdma driver - imx-sdma device to device support Other: - jz4780 fixes - ioatdma large refactor and cleanup for removal of ioat v1 and v2 which is deprecated and fixes - ACPI support in X-Gene DMA engine driver - ipu irq fixes - mvxor fixes - minor fixes spread thru drivers" [ The Kconfig and Makefile entries got re-sorted alphabetically, and I handled the conflict with the new Intel integrated IDMA driver by slightly mis-sorting it on purpose: "IDMA64" got sorted after "IMX" in order to keep the Intel entries together. I think it might be a good idea to just rename the IDMA64 config entry to INTEL_IDMA64 to make the sorting be a true sort, not this mismash. Also, this merge disables the COMPILE_TEST for the sun4i DMA controller, because it does not compile cleanly at all. - Linus ] * tag 'dmaengine-4.3-rc1' of git://git.infradead.org/users/vkoul/slave-dma: (89 commits) dmaengine: ioatdma: add Broadwell EP ioatdma PCI dev IDs dmaengine :ipu: change ipu_irq_handler() to remove compile warning dmaengine: ioatdma: Fix variable array length dmaengine: ioatdma: fix sparse "error" with prep lock dmaengine: hdmac: Add memset capabilities dmaengine: sort the sh Makefile dmaengine: sort the sh Kconfig dmaengine: sort the dw Kconfig dmaengine: sort the Kconfig dmaengine: sort the makefile drivers/dma: make mv_xor.c driver explicitly non-modular dmaengine: Add support for the Analog Devices AXI-DMAC DMA controller devicetree: Add bindings documentation for Analog Devices AXI-DMAC dmaengine: xgene-dma: Fix the lock to allow client for further submission of requests dmaengine: ioatdma: fix coccinelle warning dmaengine: ioatdma: fix zero day warning on incompatible pointer type dmaengine: tegra-apb: Simplify locking for device using global pause dmaengine: tegra-apb: Remove unnecessary return statements and variables dmaengine: tegra-apb: Avoid unnecessary channel base address calculation dmaengine: tegra-apb: Remove unused variables ...

dmaengine: hdmac: Add memset capabilities

2015-08-26T02:20:21+00:00

Just like for the XDMAC, the SoCs that embed the HDMAC don't have any kind of GPU, and need to accelerate a few framebuffer-related operations through their DMA controller. However, unlike the XDMAC, the HDMAC doesn't have the memset capability built-in. That can be easily emulated though, by doing a transfer with a fixed address on the variable that holds the value we want to set. Signed-off-by: Maxime Ripard Signed-off-by: Vinod Koul

dmaengine: at_hdmac: fix residue computation

2015-07-31T15:03:42+00:00

As claimed by the programmer datasheet and confirmed by the IP designer, the Block Transfer Size (BTSIZE) bitfield of the Channel x Control A Register (CTRLAx) always refers to a number of Source Width (SRC_WIDTH) transfers. Both the SRC_WIDTH and BTSIZE bitfields can be extacted from the CTRLAx register to compute the DMA residue. So the 'tx_width' field is useless and can be removed from the struct at_desc. Before this patch, atc_prep_slave_sg() was not consistent: BTSIZE was correctly initialized according to the SRC_WIDTH but 'tx_width' was always set to reg_width, which was incorrect for MEM_TO_DEV transfers. It led to bad DMA residue when 'tx_width' != SRC_WIDTH. Also the 'tx_width' field was mostly set only in the first and last descriptors. Depending on the kind of DMA transfer, this field remained uninitialized for intermediate descriptors. The accurate DMA residue was computed only when the currently processed descriptor was the first or the last of the chain. This algorithm was a little bit odd. An accurate DMA residue can always be computed using the SRC_WIDTH and BTSIZE bitfields in the CTRLAx register. Finally, the test to check whether the currently processed descriptor is the last of the chain was wrong: for cyclic transfer, last_desc->lli.dscr is NOT equal to zero, since set_desc_eol() is never called, but logically equal to first_desc->txd.phys. This bug has a side effect on the drivers/tty/serial/atmel_serial.c driver, which uses cyclic DMA transfer to receive data. Since the DMA residue was wrong each time the DMA transfer reaches the second (and last) period of the transfer, no more data were received by the USART driver till the cyclic DMA transfer loops back to the first period. Signed-off-by: Cyrille Pitchen Acked-by: Torsten Fleischer Tested-by: Jirí Prchal Acked-by: Nicolas Ferre Signed-off-by: Vinod Koul