linux-toradex.git/drivers/dma/mediatek, branch master

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28+00:00

This is the result of running the Coccinelle script from
scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to
avoid scalar types (which need careful case-by-case checking), and
instead replace kmalloc-family calls that allocate struct or union
object instances:

Single allocations:	kmalloc(sizeof(TYPE), ...)
are replaced with:	kmalloc_obj(TYPE, ...)

Array allocations:	kmalloc_array(COUNT, sizeof(TYPE), ...)
are replaced with:	kmalloc_objs(TYPE, COUNT, ...)

Flex array allocations:	kmalloc(struct_size(PTR, FAM, COUNT), ...)
are replaced with:	kmalloc_flex(*PTR, FAM, COUNT, ...)

(where TYPE may also be *VAR)

The resulting allocations no longer return "void *", instead returning
"TYPE *".

Signed-off-by: Kees Cook

dmaengine: mediatek: mtk-uart-apdma: Add support for Dimensity 9200

2025-12-23T11:01:24+00:00

Add a compatible string and match data for the APDMA IP version
found in the MediaTek Dimensity 9200 MT6985 SoC; this supports
extended addressing with up to 35 bits.

Other SoCs with this IP version also include the Dimensity 9400
MT6991 and Kompanio Ultra MT8196 (which don't need a specific
compatible in this driver and can reuse the mt6985 one).

Signed-off-by: AngeloGioacchino Del Regno 
Link: https://patch.msgid.link/20251113122229.23998-9-angelogioacchino.delregno@collabora.com
Signed-off-by: Vinod Koul

dmaengine: mediatek: mtk-uart-apdma: Add support for Dimensity 6300

2025-12-23T11:01:24+00:00

Add a compatible string and match data for the APDMA IP version
found in the MediaTek Dimensity 6300 MT6835 SoC; this supports
extended addressing with up to 34 bits.

Signed-off-by: AngeloGioacchino Del Regno 
Link: https://patch.msgid.link/20251113122229.23998-8-angelogioacchino.delregno@collabora.com
Signed-off-by: Vinod Koul

dmaengine: mediatek: mtk-uart-apdma: Rename support_33bits to support_ext_addr

2025-12-23T11:01:24+00:00

In preparation for adding support for SoCs with APDMA IP versions
supporting more than 33 bits addressing, rename the support_33bits
variable to support_ext_addr to signal support for extended, above
4GB, addressing.

This change is cosmetic only, and brings no functional differences.

Signed-off-by: AngeloGioacchino Del Regno 
Link: https://patch.msgid.link/20251113122229.23998-7-angelogioacchino.delregno@collabora.com
Signed-off-by: Vinod Koul

dmaengine: mediatek: uart-apdma: Fix above 4G addressing TX/RX

2025-12-23T11:01:24+00:00

The VFF_4G_SUPPORT register is named differently in datasheets,
and its name is "VFF_ADDR2"; was this named correctly from the
beginning it would've been clearer that there was a mistake in
the programming sequence.

This register is supposed to hold the high bits to support the
DMA addressing above 4G (so, more than 32 bits) and not a bit
to "enable" the support for VFF 4G.

Fix the name of this register, and also fix its usage by writing
the upper 32 bits of the dma_addr_t on it when the SoC supports
such feature.

Fixes: 9135408c3ace ("dmaengine: mediatek: Add MediaTek UART APDMA support")
Signed-off-by: AngeloGioacchino Del Regno 
Link: https://patch.msgid.link/20251113122229.23998-6-angelogioacchino.delregno@collabora.com
Signed-off-by: Vinod Koul

dmaengine: mediatek: uart-apdma: Get addressing bits from match data

2025-12-23T11:01:24+00:00

The only SoC that declares mediatek,dma-33bits in its devicetree
currently is MT6795, which obviously also declares a SoC-specific
compatible string: in preparation for adding new SoCs with 34 bits
addressing, replace the parsing of said vendor property with logic
to get the number of addressing bits from platform data associated
to compatible strings.

While at it, also make the bit_mask variable unsigned and move the
`int rc` declaration as last to beautify the code.

Thanks to the correct declaration of the APDMA node is in all of
the MediaTek device trees that are currently upstream, this commit
brings no functional differences.

Signed-off-by: AngeloGioacchino Del Regno 
Acked-by: Conor Dooley 
Link: https://patch.msgid.link/20251113122229.23998-5-angelogioacchino.delregno@collabora.com
Signed-off-by: Vinod Koul

dmaengine: mediatek: Fix a flag reuse error in mtk_cqdma_tx_status()

2025-06-26T22:09:20+00:00

Fixed a flag reuse bug in the mtk_cqdma_tx_status() function.

Fixes: 157ae5ffd76a ("dmaengine: mediatek: Fix a possible deadlock error in mtk_cqdma_tx_status()")
Cc: stable@vger.kernel.org
Reported-by: kernel test robot 
Closes: https://lore.kernel.org/oe-kbuild-all/202505270641.MStzJUfU-lkp@intel.com/
Signed-off-by: Qiu-ji Chen 
Reviewed-by: Eugen Hristev 
Reviewed-by: AngeloGioacchino Del Regno 
Link: https://lore.kernel.org/r/20250606090017.5436-1-chenqiuji666@gmail.com
Signed-off-by: Vinod Koul

dmaengine: mediatek: drop unused variable

2025-05-15T10:42:13+00:00

Commit 157ae5ffd76a dmaengine: mediatek: Fix a possible deadlock error
in mtk_cqdma_tx_status() fixed locks but kept unused varibale leading to
warning and build failure (due to warning treated as errors)

drivers/dma/mediatek/mtk-cqdma.c: In function 'mtk_cqdma_find_active_desc':
drivers/dma/mediatek/mtk-cqdma.c:423:23: error: unused variable 'flags' [-Werror=unused-variable]
  423 |         unsigned long flags;
      |                       ^~~~~

Fix by dropping this unused flag

Reported-by: Stephen Rothwell 
Fixes: 157ae5ffd76a ("dmaengine: mediatek: Fix a possible deadlock error in mtk_cqdma_tx_status()")
Signed-off-by: Vinod Koul

dmaengine: mediatek: Fix a possible deadlock error in mtk_cqdma_tx_status()

2025-05-14T13:54:31+00:00

Fix a potential deadlock bug. Observe that in the mtk-cqdma.c
file, functions like mtk_cqdma_issue_pending() and
mtk_cqdma_free_active_desc() properly acquire the pc lock before the vc
lock when handling pc and vc fields. However, mtk_cqdma_tx_status()
violates this order by first acquiring the vc lock before invoking
mtk_cqdma_find_active_desc(), which subsequently takes the pc lock. This
reversed locking sequence (vc → pc) contradicts the established
pc → vc order and creates deadlock risks.

Fix the issue by moving the vc lock acquisition code from
mtk_cqdma_find_active_desc() to mtk_cqdma_tx_status(). Ensure the pc lock
is acquired before the vc lock in the calling function to maintain correct
locking hierarchy. Note that since mtk_cqdma_find_active_desc() is a
static function with only one caller (mtk_cqdma_tx_status()), this
modification safely eliminates the deadlock possibility without affecting
other components.

This possible bug is found by an experimental static analysis tool
developed by our team. This tool analyzes the locking APIs to extract
function pairs that can be concurrently executed, and then analyzes the
instructions in the paired functions to identify possible concurrency bugs
including deadlocks, data races and atomicity violations.

Fixes: b1f01e48df5a ("dmaengine: mediatek: Add MediaTek Command-Queue DMA controller for MT6765 SoC")
Cc: stable@vger.kernel.org
Signed-off-by: Qiu-ji Chen 
Reviewed-by: AngeloGioacchino Del Regno 
Link: https://lore.kernel.org/r/20250508073634.3719-1-chenqiuji666@gmail.com
Signed-off-by: Vinod Koul

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