kernel/linux.git/drivers/dma/altera-msgdma.c, branch v6.19.11

dmaengine: Switch back to struct platform_driver::remove()

2024-10-14T18:20:34+00:00

After commit 0edb555a65d1 ("platform: Make platform_driver::remove() return void") .remove() is (again) the right callback to implement for platform drivers. Convert all platform drivers below drivers/dma after the previous conversion commits apart from the wireless drivers to use .remove(), with the eventual goal to drop struct platform_driver::remove_new(). As .remove() and .remove_new() have the same prototypes, conversion is done by just changing the structure member name in the driver initializer. Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20241004062227.187726-2-u.kleine-koenig@baylibre.com Signed-off-by: Vinod Koul

dmaengine: Fix spelling mistakes

2024-09-02T08:26:01+00:00

Correct spelling mistakes in the DMA engine to improve readability and clarity without altering functionality. Signed-off-by: Amit Vadhavana Reviewed-by: Kees Cook Reviewed-by: Dave Jiang Reviewed-by: Fenghua Yu Link: https://lore.kernel.org/r/20240831172949.13189-1-av2082000@gmail.com Signed-off-by: Vinod Koul

dmaengine: altera-msgdma: properly free descriptor in msgdma_free_descriptor

2024-06-11T16:20:55+00:00

Remove list_del call in msgdma_chan_desc_cleanup, this should be the role of msgdma_free_descriptor. In consequence replace list_add_tail with list_move_tail in msgdma_free_descriptor. This fixes the path: msgdma_free_chan_resources -> msgdma_free_descriptors -> msgdma_free_desc_list -> msgdma_free_descriptor which does not correctly free the descriptors as first nodes were not removed from the list. Signed-off-by: Olivier Dautricourt Tested-by: Olivier Dautricourt Link: https://lore.kernel.org/r/20240608213216.25087-3-olivierdautricourt@gmail.com Signed-off-by: Vinod Koul

dmaengine: altera-msgdma: cleanup after completing all descriptors

2024-06-11T16:20:55+00:00

msgdma_chan_desc_cleanup iterates the done list for each completed descriptor while we need to do it once after all descriptors are completed. This fixes a Sparse warning because we first take the lock in msgdma_tasklet. - Move locking to msgdma_chan_desc_cleanup. - Move call to msgdma_chan_desc_cleanup outside of the critical section of msgdma_tasklet. Inspired by: commit 16ed0ef3e931 ("dmaengine: zynqmp_dma: cleanup after completing all descriptors") Signed-off-by: Olivier Dautricourt Tested-by: Olivier Dautricourt Suggested-by: Eric Schwarz Link: https://lore.kernel.org/r/20240608213216.25087-2-olivierdautricourt@gmail.com Signed-off-by: Vinod Koul

dmaengine: altera-msgdma: use irq variant of spin_lock/unlock while invoking callbacks

2024-06-11T16:20:55+00:00

As we first take the lock with spin_lock_irqsave in msgdma_tasklet, Lockdep might complain about this. Inspired by commit 9558cf4ad07e ("dmaengine: zynqmp_dma: fix lockdep warning in tasklet") Signed-off-by: Olivier Dautricourt Tested-by: Olivier Dautricourt Suggested-by: Eric Schwarz Link: https://lore.kernel.org/r/20240608213216.25087-1-olivierdautricourt@gmail.com Signed-off-by: Vinod Koul

dmaengine: altera-msgdma: Convert to platform remove callback returning void

2023-09-28T07:40:45+00:00

The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König Acked-by: Olivier Dautricourt Link: https://lore.kernel.org/r/20230919133207.1400430-2-u.kleine-koenig@pengutronix.de Signed-off-by: Vinod Koul

dmaengine: altera-msgdma: Fixed some inconsistent function name descriptions

2022-07-06T16:30:06+00:00

Inconsistent function names describing msgdma_chan_remove() and msgdma_dma_remove are modified to msgdma_dev_remove() and msgdma_remove(). Remove some warnings found by running scripts/kernel-doc, which is caused by using 'make W=1'. drivers/dma/altera-msgdma.c:927: warning: expecting prototype for msgdma_dma_remove(). Prototype was for msgdma_remove() instead. drivers/dma/altera-msgdma.c:758: warning: expecting prototype for msgdma_chan_remove(). Prototype was for msgdma_dev_remove() instead. Signed-off-by: Jiapeng Chong Reviewed-by: Stefan Roese Link: https://lore.kernel.org/r/20220706082605.114907-1-jiapeng.chong@linux.alibaba.com Signed-off-by: Vinod Koul

dmaengine: altera-msgdma: Remove useless DMA-32 fallback configuration

2022-02-15T11:23:11+00:00

As stated in [1], dma_set_mask() with a 64-bit mask never fails if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. Simplify code and remove some dead code accordingly. [1]: https://lore.kernel.org/linux-kernel/YL3vSPK5DXTNvgdx@infradead.org/#t Signed-off-by: Christophe JAILLET Reviewed-by: Stefan Roese Acked-by: Olivier Dautricourt Link: https://lore.kernel.org/r/01058ada3a0dea207212182ca7525060a204f1e1.1642232423.git.christophe.jaillet@wanadoo.fr Signed-off-by: Vinod Koul

dmaengine: altera-msgdma: Correctly handle descriptor callbacks

2021-10-28T17:23:54+00:00

DMA clients can provide one of two types of callbacks. For this reason dmaengine drivers should not directly invoke `callback`, but always use dmaengine_desc_callback_invoke(). This makes sure that both types of callbacks are handled correctly. The altera-msgdma driver currently doesn't do this and only handles the `callback` type callback. If the client used the `callback_result` type callback it will not be called. Fix this by switching to `dmaengine_desc_callback_valid()` and `dmaengine_desc_callback_invoke()`. Signed-off-by: Lars-Peter Clausen Link: https://lore.kernel.org/r/20211025075428.2094-1-lars@metafoo.de Signed-off-by: Vinod Koul

dmaengine: altera-msgdma: make response port optional

2021-07-28T06:55:10+00:00

The response slave port can be disabled in some configuration [1] and csr + MSGDMA_CSR_RESP_FILL_LEVEL will be 0 even if transfer has suceeded. We have to only rely on the interrupts in that scenario. This was tested on cyclone V with the controller resp port disabled. [1] https://www.intel.com/content/www/us/en/programmable/documentation/sfo1400787952932.html 30.3.1.2 30.3.1.3 30.5.5 Fixes: https://forum.rocketboards.org/t/ip-msgdma-linux-driver/1919 Signed-off-by: Olivier Dautricourt Reviewed-by: Stefan Roese Link: https://lore.kernel.org/r/8220756f2191ca08cb21702252d1f2d4f753a7f5.1623898678.git.olivier.dautricourt@orolia.com Signed-off-by: Vinod Koul