linux-stable.git/drivers/dma, branch v5.19.4

dmaengine: sprd: Cleanup in .remove() after pm_runtime_get_sync() failed

2022-08-25T09:45:46+00:00

[ Upstream commit 1e42f82cbec7b2cc4873751e7791e6611901c5fc ]

It's not allowed to quit remove early without cleaning up completely.
Otherwise this results in resource leaks that probably yield graver
problems later. Here for example some tasklets might survive the lifetime
of the sprd-dma device and access sdev which is freed after .remove()
returns.

As none of the device freeing requires an active device, just ignore the
return value of pm_runtime_get_sync().

Signed-off-by: Uwe Kleine-König 
Reviewed-by: Baolin Wang 
Link: https://lore.kernel.org/r/20220721204054.323602-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

dmaengine: tegra: Add terminate() for Tegra234

2022-08-25T09:45:46+00:00

[ Upstream commit 36834c67016794b8fa03d7672a5b7f2cc4529298 ]

In certain cases where the DMA client bus gets corrupted or if the
end device ceases to send/receive data, DMA can wait indefinitely
for the data to be received/sent. Attempting to terminate the transfer
will put the DMA in pause flush mode and it remains there.

The channel is irrecoverable once this pause times out in Tegra194 and
earlier chips. Whereas, from Tegra234, it can be recovered by disabling
the channel and reprograming it.

Hence add a new terminate() function that ignores the outcome of
dma_pause() so that terminate_all() can proceed to disable the channel.

Signed-off-by: Akhil R 
Reviewed-by: Jon Hunter 
Link: https://lore.kernel.org/r/20220720104045.16099-3-akhilrajeev@nvidia.com
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

dmaengine: dw-axi-dmac: ignore interrupt if no descriptor

2022-08-25T09:45:45+00:00

[ Upstream commit 820f5ce999d2f99961e88c16d65cd26764df0590 ]

If the channel has no descriptor and the interrupt is raised then the
kernel will OOPS. Check the result of vchan_next_desc() in the handler
axi_chan_block_xfer_complete() to avoid the error happening.

Signed-off-by: Ben Dooks 
Link: https://lore.kernel.org/r/20220708170153.269991-4-ben.dooks@sifive.com
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

dmaengine: dw-axi-dmac: do not print NULL LLI during error

2022-08-25T09:45:45+00:00

[ Upstream commit 86cb0defe0e275453bc39e856bb523eb425a6537 ]

During debugging we have seen an issue where axi_chan_dump_lli()
is passed a NULL LLI pointer which ends up causing an OOPS due
to trying to get fields from it. Simply print NULL LLI and exit
to avoid this.

Signed-off-by: Ben Dooks 
Link: https://lore.kernel.org/r/20220708170153.269991-3-ben.dooks@sifive.com
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

dmaengine: imx-dma: Cast of_device_get_match_data() with (uintptr_t)

2022-08-17T13:15:36+00:00

[ Upstream commit c3266ee185b59e5aab3e0f982e5b7f95d31555a7 ]

Change the of_device_get_match_data() cast to (uintptr_t)
to silence the following clang warning:

drivers/dma/imx-dma.c:1048:20: warning: cast to smaller integer type 'enum imx_dma_type' from 'const void *' [-Wvoid-pointer-to-enum-cast]

Reported-by: kernel test robot 
Fixes: 0ab785c894e6 ("dmaengine: imx-dma: Remove unused .id_table")
Signed-off-by: Fabio Estevam 
Link: https://lore.kernel.org/r/20220706111327.940764-1-festevam@gmail.com
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

dmaengine: sf-pdma: Add multithread support for a DMA channel

2022-08-17T13:15:28+00:00

[ Upstream commit b2cc5c465c2cb8ab697c3fd6583c614e3f6cfbcc ]

When we get a DMA channel and try to use it in multiple threads it
will cause oops and hanging the system.

% echo 64 > /sys/module/dmatest/parameters/threads_per_chan
% echo 10000 > /sys/module/dmatest/parameters/iterations
% echo 1 > /sys/module/dmatest/parameters/run
[ 89.480664] Unable to handle kernel NULL pointer dereference at virtual
address 00000000000000a0
[ 89.488725] Oops [#1]
[ 89.494708] CPU: 2 PID: 1008 Comm: dma0chan0-copy0 Not tainted
5.17.0-rc5
[ 89.509385] epc : vchan_find_desc+0x32/0x46
[ 89.513553] ra : sf_pdma_tx_status+0xca/0xd6

This happens because of data race. Each thread rewrite channels's
descriptor as soon as device_prep_dma_memcpy() is called. It leads to the
situation when the driver thinks that it uses right descriptor that
actually is freed or substituted for other one.

With current fixes a descriptor changes its value only when it has
been used. A new descriptor is acquired from vc->desc_issued queue that
is already filled with descriptors that are ready to be sent. Threads
have no direct access to DMA channel descriptor. Now it is just possible
to queue a descriptor for further processing.

Fixes: 6973886ad58e ("dmaengine: sf-pdma: add platform DMA support for HiFive Unleashed A00")
Signed-off-by: Viacheslav Mitrofanov
Link: https://lore.kernel.org/r/20220701082942.12835-1-v.v.mitrofanov@yadro.com
Signed-off-by: Vinod Koul
Signed-off-by: Sasha Levin

dmaengine: dw-edma: Fix eDMA Rd/Wr-channels and DMA-direction semantics

2022-08-17T13:15:22+00:00

[ Upstream commit c1e33979171da63cf47e56243ccb8ba82363c7d3 ]

In accordance with [1, 2] the DW eDMA controller has been created to be
part of the DW PCIe Root Port and DW PCIe End-point controllers and to
offload the transferring of large blocks of data between application and
remote PCIe domains leaving the system CPU free for other tasks. In the
first case (eDMA being part of DW PCIe Root Port) the eDMA controller is
always accessible via the CPU DBI interface and never over the PCIe wire.

The latter case is more complex. Depending on the DW PCIe End-Point IP-core
synthesize parameters it's possible to have the eDMA registers accessible
not only from the application CPU side, but also via mapping the eDMA CSRs
over a dedicated endpoint BAR. So based on the specifics denoted above the
eDMA driver is supposed to support two types of the DMA controller setups:

  1) eDMA embedded into the DW PCIe Root Port/End-point and accessible over
     the local CPU from the application side.

  2) eDMA embedded into the DW PCIe End-point and accessible via the PCIe
     wire with MWr/MRd TLPs generated by the CPU PCIe host controller.

Since the CPU memory resides different sides in these cases the semantics
of the MEM_TO_DEV and DEV_TO_MEM operations is flipped with respect to the
Tx and Rx DMA channels. So MEM_TO_DEV/DEV_TO_MEM corresponds to the Tx/Rx
channels in setup 1) and to the Rx/Tx channels in case of setup 2).

The DW eDMA driver has supported the case 2) since e63d79d1ffcd
("dmaengine: Add Synopsys eDMA IP core driver") in the framework of the
drivers/dma/dw-edma/dw-edma-pcie.c driver.

The case 1) support was added later by bd96f1b2f43a ("dmaengine: dw-edma:
support local dma device transfer semantics").  Afterwards the driver was
supposed to cover the both possible eDMA setups, but the latter commit
turned out to be not fully correct.

The problem was that the commit together with the new functionality support
also changed the channel direction semantics so the eDMA Read-channel
(corresponding to the DMA_DEV_TO_MEM direction for case 1) now uses the
sgl/cyclic base addresses as the Source addresses of the DMA transfers and
dma_slave_config.dst_addr as the Destination address of the DMA transfers.

Similarly the eDMA Write-channel (corresponding to the DMA_MEM_TO_DEV
direction for case 1) now uses dma_slave_config.src_addr as a source
address of the DMA transfers and sgl/cyclic base address as the Destination
address of the DMA transfers. This contradicts the logic of the
DMA-interface, which implies that DEV side is supposed to belong to the
PCIe device memory and MEM - to the CPU/Application memory. Indeed it seems
irrational to have the SG-list defined in the PCIe bus space, while
expecting a contiguous buffer allocated in the CPU memory. Moreover the
passed SG-list and cyclic DMA buffers are supposed to be mapped in a way so
to be seen by the DW eDMA Application (CPU) interface.

So in order to have the correct DW eDMA interface we need to invert the
eDMA Rd/Wr-channels and DMA-slave directions semantics by selecting the
src/dst addresses based on the DMA transfer direction instead of using the
channel direction capability.

[1] DesignWare Cores PCI Express Controller Databook - DWC PCIe Root Port,
    v.5.40a, March 2019, p.1092
[2] DesignWare Cores PCI Express Controller Databook - DWC PCIe Endpoint,
    v.5.40a, March 2019, p.1189

Co-developed-by: Manivannan Sadhasivam 
Fixes: bd96f1b2f43a ("dmaengine: dw-edma: support local dma device transfer semantics")
Link: https://lore.kernel.org/r/20220524152159.2370739-7-Frank.Li@nxp.com
Tested-by: Manivannan Sadhasivam 
Signed-off-by: Manivannan Sadhasivam 
Signed-off-by: Serge Semin 
Signed-off-by: Frank Li 
Signed-off-by: Bjorn Helgaas 
Acked-By: Vinod Koul 
Signed-off-by: Sasha Levin

dmaengine: dw: dmamux: Fix build without CONFIG_OF

2022-08-17T13:15:05+00:00

[ Upstream commit 7811f2e7fd6a30d96eaa1fccf57b07694a8cad27 ]

When built without OF support, of_match_node() expands to NULL, which
produces the following output:
>> drivers/dma/dw/rzn1-dmamux.c:105:34: warning: unused variable 'rzn1_dmac_match' [-Wunused-const-variable]
   static const struct of_device_id rzn1_dmac_match[] = {

One way to silence the warning is to enclose the structure definition
with an #ifdef CONFIG_OF/#endif block.

Fixes: 134d9c52fca2 ("dmaengine: dw: dmamux: Introduce RZN1 DMA router support")
Reported-by: kernel test robot 
Signed-off-by: Miquel Raynal 
Reviewed-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20220609141455.300879-2-miquel.raynal@bootlin.com
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

dmaengine: dw: dmamux: Export the module device table

2022-08-17T13:15:05+00:00

[ Upstream commit 2717d33841957a0f5fb65fd8b37f9c2321593864 ]

This is a tristate driver that can be built as a module, as a result,
the OF match table should be exported with MODULE_DEVICE_TABLE().

Fixes: 134d9c52fca2 ("dmaengine: dw: dmamux: Introduce RZN1 DMA router support")
Signed-off-by: Miquel Raynal 
Reviewed-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20220609141455.300879-1-miquel.raynal@bootlin.com
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

dmaengine: lgm: Fix an error handling path in intel_ldma_probe()

2022-07-06T05:23:25+00:00

ldma_clk_disable() calls both:
	clk_disable_unprepare(d->core_clk);
	reset_control_assert(d->rst);

So, should devm_reset_control_get_optional() fail, core_clk should not
be prepare_enable'd before it, otherwise it will never be
disable_unprepare'd.

Reorder the code to handle the error handling path as expected.

Fixes: 32d31c79a1a4 ("dmaengine: Add Intel LGM SoC DMA support.")
Signed-off-by: Christophe JAILLET 
Link: https://lore.kernel.org/r/18504549bc4d2b62a72a02cb22a2e4d8e6a58720.1653241224.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Vinod Koul