linux-stable.git/drivers/dma/qcom, branch linux-4.9.y

dmaengine: QCOM_HIDMA_MGMT depends on HAS_IOMEM

2021-06-30T12:49:12+00:00

[ Upstream commit 0cfbb589d67f16fa55b26ae02b69c31b52e344b1 ]

When CONFIG_HAS_IOMEM is not set/enabled, certain iomap() family
functions [including ioremap(), devm_ioremap(), etc.] are not
available.
Drivers that use these functions should depend on HAS_IOMEM so that
they do not cause build errors.

Rectifies these build errors:
s390-linux-ld: drivers/dma/qcom/hidma_mgmt.o: in function `hidma_mgmt_probe':
hidma_mgmt.c:(.text+0x780): undefined reference to `devm_ioremap_resource'
s390-linux-ld: drivers/dma/qcom/hidma_mgmt.o: in function `hidma_mgmt_init':
hidma_mgmt.c:(.init.text+0x126): undefined reference to `of_address_to_resource'
s390-linux-ld: hidma_mgmt.c:(.init.text+0x16e): undefined reference to `of_address_to_resource'

Fixes: 67a2003e0607 ("dmaengine: add Qualcomm Technologies HIDMA channel driver")
Signed-off-by: Randy Dunlap 
Reported-by: kernel test robot 
Cc: Sinan Kaya 
Cc: Vinod Koul 
Cc: dmaengine@vger.kernel.org
Link: https://lore.kernel.org/r/20210522021313.16405-3-rdunlap@infradead.org
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

dmaengine: qcom_hidma: comment platform_driver_register call

2021-06-03T06:23:31+00:00

[ Upstream commit 4df2a8b0ad634d98a67e540a4e18a60f943e7d9f ]

Place a comment in hidma_mgmt_init explaining why success must
currently be assumed, due to the cleanup issue that would need to
be considered were this module ever to be unloadable or were this
platform_driver_register call ever to fail.

Acked-By: Vinod Koul 
Acked-By: Sinan Kaya 
Signed-off-by: Phillip Potter 
Link: https://lore.kernel.org/r/20210503115736.2104747-52-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

dmaengine: qcom: bam_dma: Fix resource leak

2019-11-10T10:23:31+00:00

commit 7667819385457b4aeb5fac94f67f52ab52cc10d5 upstream.

bam_dma_terminate_all() will leak resources if any of the transactions are
committed to the hardware (present in the desc fifo), and not complete.
Since bam_dma_terminate_all() does not cause the hardware to be updated,
the hardware will still operate on any previously committed transactions.
This can cause memory corruption if the memory for the transaction has been
reassigned, and will cause a sync issue between the BAM and its client(s).

Fix this by properly updating the hardware in bam_dma_terminate_all().

Fixes: e7c0fe2a5c84 ("dmaengine: add Qualcomm BAM dma driver")
Signed-off-by: Jeffrey Hugo 
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20191017152606.34120-1-jeffrey.l.hugo@gmail.com
Signed-off-by: Vinod Koul 
Signed-off-by: Greg Kroah-Hartman

dmaengine: qcom_hidma: assign channel cookie correctly

2019-04-05T20:29:14+00:00

[ Upstream commit 546c0547555efca8ba8c120716c325435e29df1b ]

When dma_cookie_complete() is called in hidma_process_completed(),
dma_cookie_status() will return DMA_COMPLETE in hidma_tx_status(). Then,
hidma_txn_is_success() will be called to use channel cookie
mchan->last_success to do additional DMA status check. Current code
assigns mchan->last_success after dma_cookie_complete(). This causes
a race condition of dma_cookie_status() returns DMA_COMPLETE before
mchan->last_success is assigned correctly. The race will cause
hidma_tx_status() return DMA_ERROR but the transaction is actually a
success. Moreover, in async_tx case, it will cause a timeout panic
in async_tx_quiesce().

 Kernel panic - not syncing: async_tx_quiesce: DMA error waiting for
 transaction
 ...
 Call trace:
 [] dump_backtrace+0x0/0x1f4
 [] show_stack+0x24/0x2c
 [] dump_stack+0x84/0xa8
 [] panic+0x12c/0x29c
 [] async_tx_quiesce+0xa4/0xc8 [async_tx]
 [] async_trigger_callback+0x70/0x1c0 [async_tx]
 [] raid_run_ops+0x86c/0x1540 [raid456]
 [] handle_stripe+0x5e8/0x1c7c [raid456]
 [] handle_active_stripes.isra.45+0x2d4/0x550 [raid456]
 [] raid5d+0x38c/0x5d0 [raid456]
 [] md_thread+0x108/0x168
 [] kthread+0x10c/0x138
 [] ret_from_fork+0x10/0x18

Cc: Joey Zheng 
Reviewed-by: Sinan Kaya 
Signed-off-by: Shunyong Yang 
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

dmaengine: qcom: bam_dma: get num-channels and num-ees from dt

2018-05-30T05:50:48+00:00

[ Upstream commit 48d163b1aa6e7f650c0b7a4f9c61c387a6def868 ]

When Linux is master of BAM, it can directly read registers to know number
of supported channels, however when its remotely controlled reading these
registers would trigger a crash if the BAM is not yet initialized or
powered up on the remote side.

This patch allows driver to read num-channels and num-ees from Device Tree
for remotely controlled BAM.

Signed-off-by: Srinivas Kandagatla 
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

dmaengine: qcom_hidma: add error reporting for tx_status

2016-08-31T15:57:32+00:00

The HIDMA driver is capable of error detection. However, the error was
not being passed back to the client when tx_status API is called.

Changing the error handling behavior to follow this oder.

1. dmaengine asserts error interrupt
2. Driver receives and mark's the txn as error
3. Driver completes the txn and intimates the client. No further
   submissions. Drop the locks before calling callback, as subsequent
   processing by client maybe in callback thread.
4. Client invokes status and you can return error
5. On error, client calls terminate_all. You can reset channel, free all
   descriptors in the active, pending and completed lists
6. Client prepares new txn and so on.

As part of this work, got rid of the reset in the interrupt handler when
an error happens and the HW is put into disabled state. The only way to
recover is for the client to terminate the channel.

Signed-off-by: Sinan Kaya 
Signed-off-by: Vinod Koul

dmaengine: qcom_hidma: report transfer errors with new interface

2016-08-31T15:57:32+00:00

Pass the DMA errors to the client by passing a result argument. The HW only
supports a generic error when something goes wrong. That's why, using
DMA_TRANS_ABORTED all the time.

Signed-off-by: Sinan Kaya 
Signed-off-by: Vinod Koul

dmaengine: qcom_hidma: release the descriptor before the callback

2016-08-31T15:57:32+00:00

There is a race condition between data transfer callback and descriptor
free code. The callback routine may decide to clear the resources even
though the descriptor has not yet been freed.

Instead of calling the callback first and then releasing the memory,
this code is changing the order to return the descriptor back to the
free pool and then call the user provided callback.

Signed-off-by: Sinan Kaya 
Signed-off-by: Vinod Koul

dmaengine: qcom_hidma: convert callback to helper function

2016-08-08T02:41:41+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 
Acked-by: Sinan Kaya 
Signed-off-by: Vinod Koul

Merge branch 'topic/dmaengine_cleanups' into for-linus

2016-07-28T04:40:37+00:00