Pull dmaengine updates from Vinod Koul:

 - Big pile of __counted_by attribute annotations to several structures
   for bounds checking of flexible arrays at run-time

 - Another big pile platform remove callback returning void changes

 - Device tree device_get_match_data() usage and dropping
   of_match_device() calls

 - Minor driver updates to pxa, idxd fsl, hisi etc drivers

* tag 'dmaengine-6.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine: (106 commits)
  dmaengine: stm32-mdma: correct desc prep when channel running
  dmaengine: dw-axi-dmac: Add support DMAX_NUM_CHANNELS > 16
  dmaengine: xilinx: xilinx_dma: Fix kernel doc about xilinx_dma_remove()
  dmaengine: mmp_tdma: drop unused variable 'of_id'
  MAINTAINERS: Add entries for NXP(Freescale) eDMA drivers
  dmaengine: xilinx: xdma: Support cyclic transfers
  dmaengine: xilinx: xdma: Prepare the introduction of cyclic transfers
  dmaengine: Drop unnecessary of_match_device() calls
  dmaengine: Use device_get_match_data()
  dmaengine: pxa_dma: Annotate struct pxad_desc_sw with __counted_by
  dmaengine: pxa_dma: Remove an erroneous BUG_ON() in pxad_free_desc()
  dmaengine: xilinx: xdma: Use resource_size() in xdma_probe()
  dmaengine: fsl-dpaa2-qdma: Remove redundant initialization owner in dpaa2_qdma_driver
  dmaengine: Remove unused declaration dma_chan_cleanup()
  dmaengine: mmp: fix Wvoid-pointer-to-enum-cast warning
  dmaengine: qcom: fix Wvoid-pointer-to-enum-cast warning
  dmaengine: fsl-edma: Remove redundant dev_err() for platform_get_irq()
  dmaengine: ep93xx_dma: Annotate struct ep93xx_dma_engine with __counted_by
  dmaengine: idxd: add wq driver name support for accel-config user tool
  dmaengine: fsl-edma: Annotate struct struct fsl_edma_engine with __counted_by
  ...

In case of the prep descriptor while the channel is already running, the
CCR register value stored into the channel could already have its EN bit
set.  This would lead to a bad transfer since, at start transfer time,
enabling the channel while other registers aren't yet properly set.
To avoid this, ensure to mask the CCR_EN bit when storing the ccr value
into the mdma channel structure.

Fixes: a4ffb13c8946 ("dmaengine: Add STM32 MDMA driver")
Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
Cc: stable@vger.kernel.org
Tested-by: Alain Volmat <alain.volmat@foss.st.com>
Link: https://lore.kernel.org/r/20231009082450.452877-1-amelie.delaunay@foss.st.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>

Added support for DMA controller with more than 16 channels.

Signed-off-by: Sergey Khimich <serghox@gmail.com>
Link: https://lore.kernel.org/r/20231010101450.2949126-2-serghox@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>

Since commit cc99582d46b4 ("dmaengine: xilinx: xilinx_dma: Convert to
platform remove callback returning void") xilinx_dma_remove() doesn't
return zero any more. As the function has no return value any more, just
drop the statement about the return value.

Reported-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231014211656.1512016-2-u.kleine-koenig@pengutronix.de
Signed-off-by: Vinod Koul <vkoul@kernel.org>

Pull dmaengine fixes from Vinod Koul:
 "Driver fixes for:

   - stm32 dma residue calculation and chaining

   - stm32 mdma for setting inflight bytes, residue calculation and
     resume abort

   - channel request, channel enable and dma error in fsl_edma

   - runtime pm imbalance in ste_dma40 driver

   - deadlock fix in mediatek driver"

* tag 'dmaengine-fix-6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine:
  dmaengine: fsl-edma: fix all channels requested when call fsl_edma3_xlate()
  dmaengine: stm32-dma: fix residue in case of MDMA chaining
  dmaengine: stm32-dma: fix stm32_dma_prep_slave_sg in case of MDMA chaining
  dmaengine: stm32-mdma: set in_flight_bytes in case CRQA flag is set
  dmaengine: stm32-mdma: use Link Address Register to compute residue
  dmaengine: stm32-mdma: abort resume if no ongoing transfer
  dmaengine: ste_dma40: Fix PM disable depth imbalance in d40_probe
  dmaengine: mediatek: Fix deadlock caused by synchronize_irq()
  dmaengine: idxd: use spin_lock_irqsave before wait_event_lock_irq
  dmaengine: fsl-edma: fix edma4 channel enable failure on second attempt
  dt-bindings: dmaengine: zynqmp_dma: add xlnx,bus-width required property
  dmaengine: fsl-dma: fix DMA error when enabling sg if 'DONE' bit is set

Recent change a67ba97dfb30 ("dmaengine: Use device_get_match_data()")
cleaned up device tree data calls but left an unused variable, so drop
that

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Fixes: a67ba97dfb30 ("dmaengine: Use device_get_match_data()")
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Link: https://lore.kernel.org/r/20231010065729.29385-1-vkoul@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>

dma_get_slave_channel() increases client_count for all channels. It should
only be called when a matched channel is found in fsl_edma3_xlate().

Move dma_get_slave_channel() after checking for a matched channel.

Cc: stable@vger.kernel.org
Fixes: 72f5801a4e2b ("dmaengine: fsl-edma: integrate v3 support")
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Link: https://lore.kernel.org/r/20231004142911.838916-1-Frank.Li@nxp.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>

In case of MDMA chaining, DMA is configured in Double-Buffer Mode (DBM)
with two periods, but if transfer has been prepared with _prep_slave_sg(),
the transfer is not marked cyclic (=!chan->desc->cyclic). However, as DBM
is activated for MDMA chaining, residue computation must take into account
cyclic constraints.

With only two periods in MDMA chaining, and no update due to Transfer
Complete interrupt masked, n_sg is always 0. If DMA current memory address
(depending on SxCR.CT and SxM0AR/SxM1AR) does not correspond, it means n_sg
should be increased.
Then, the residue of the current period is the one read from SxNDTR and
should not be overwritten with the full period length.

Fixes: 723795173ce1 ("dmaengine: stm32-dma: add support to trigger STM32 MDMA")
Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20231004155024.2609531-2-amelie.delaunay@foss.st.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>

Current Target (CT) have to be reset when starting an MDMA chaining use
case, as Double Buffer mode is activated. It ensures the DMA will start
processing the first memory target (pointed with SxM0AR).

Fixes: 723795173ce1 ("dmaengine: stm32-dma: add support to trigger STM32 MDMA")
Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20231004155024.2609531-1-amelie.delaunay@foss.st.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>

CRQA flag is set by hardware when the channel request become active and
the channel is enabled. It is cleared by hardware, when the channel request
is completed.
So when it is set, it means MDMA is transferring bytes.
This information is useful in case of STM32 DMA and MDMA chaining,
especially when the user pauses DMA before stopping it, to trig one last
MDMA transfer to get the latest bytes of the SRAM buffer to the
destination buffer.
STM32 DCMI driver can then use this to know if the last MDMA transfer in
case of chaining is done.

Fixes: 696874322771 ("dmaengine: stm32-mdma: add support to be triggered by STM32 DMA")
Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20231004163531.2864160-3-amelie.delaunay@foss.st.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>