Re: [PATCH v2 2/4] dmaengine: Add STM32 DMA driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 14/10/15 14:17, M'boumba Cedric Madianga wrote:
Hi Daniel,

+
+static int stm32_dma_remove(struct platform_device *pdev)
+{
+       struct stm32_dma_device *dmadev = platform_get_drvdata(pdev);
+
+       of_dma_controller_free(pdev->dev.of_node);
+
+       dma_async_device_unregister(&dmadev->ddev);
+
+       clk_disable_unprepare(dmadev->clk);


What is the purpose of disabling/unpreparing the clock here?
stm32_dma_alloc_chan_resources() and stm32_dma_free_chan_resources() should
pair up and the clock should already be stopped.

stm32_dma_remove() could be called during an on-going transfer during
module unload.
So in that case, it seems that disabling/unpreparing the clock is needed.

Really?

I think we need to be sure any on-going transfers are stopped.

There are multiple reasons for this, not least the risk of executing a callback that has been freed, but the one related to my point is that a single clk_disable_unprepare() will remain broken because if you don't know that the transfers have stopped then you don't know how many on-going transfers there are.


Daniel.
--
To unsubscribe from this list: send the line "unsubscribe dmaengine" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux PCI]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux