Re: [PATCH 1/3] dt-bindings: dma: loongson: Add Loongson-2 DMA mux request IDs

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] dma: loongson: hardcoding physical DMA channel in device tree
- [Low] dma: loongson: expose LS2K0300_DMA_REQ_MAX in binding header
--

commit e4e9feb04bfe5cf0cae531423dc7021c3d20e99c
Author: Binbin Zhou <zhoubinbin@loongson.cn>

dt-bindings: dma: loongson: Add Loongson-2 DMA mux request IDs

Add DT binding constants for the Loongson-2 DMA mux. It covers UART,
I2C, SPI, I2S, ADC, and CAN peripherals for Loongson-2K0300. It also
documents channel-pair semantics for peripherals using paired channels.

> diff --git a/include/dt-bindings/dma/loongson,ls2k-dmamux.h b/include/dt-bindings/dma/loongson,ls2k-dmamux.h
> new file mode 100644
> index 0000000000000..dcc8df86befbb
> --- /dev/null
> +++ b/include/dt-bindings/dma/loongson,ls2k-dmamux.h
> @@ -0,0 +1,56 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> +/*
> + * Loongson-2 SoC DMA Mux dt-bindings
> + *
> + * DMA specifier format:
> + *   dmas = <&dma_mux <request> <channel> <flags>>;
> + *
> + * The <channel> cell selects a physical CMC DMA channel (0-7)

[Severity: Medium]
Does this design hardcode software resource allocation policy into the hardware
description?

Device trees should describe immutable hardware wiring rather than software
policy. Since the Loongson DMA mux is flexible (e.g., UART0 can be mapped to
one of 4 channel pairs via a 2-bit register field), shouldn't the OS DMA
engine dynamically allocate an available channel from a pool and program the
mux accordingly?

Statically assigning the channel in the DT shifts this policy to the hardware
description, preventing dynamic allocation and risking runtime resource
conflicts if multiple peripherals concurrently request the same statically
assigned channel.

> + * For peripherals using channel pairs (UART, I2C, SPI2/3, I2S),
> + * the channel number selects the pair: 0/1 -> pair 0, 2/3 -> pair 1,
> + * 4/5 -> pair 2, 6/7 -> pair 3.
> + *
> + * Copyright (C) 2026 Loongson Technology Corporation Limited
> + */

[ ... ]

> +/* CAN-FD controllers */
> +#define LS2K0300_DMA_CAN0		18
> +#define LS2K0300_DMA_CAN1		19
> +#define LS2K0300_DMA_CAN2		20
> +#define LS2K0300_DMA_CAN3		21
> +
> +/* Total number of 2K0300 DMA requests */
> +#define LS2K0300_DMA_REQ_MAX		22

[Severity: Low]
Is it safe to expose LS2K0300_DMA_REQ_MAX in a device tree binding header?

Device tree binding headers define the stable ABI between the hardware
description and the operating system. Exposing a _MAX macro is a known DT
anti-pattern.

If future hardware revisions or bindings add new request IDs, updating the _MAX
macro breaks backward compatibility with older compiled device trees or drivers
that rely on the previous value, potentially leading to out-of-bounds accesses
or ABI mismatches.

Should this macro be removed from the ABI header to prevent misuse?

> +
> +#endif /* _DT_BINDINGS_DMA_LOONGSON_LS2K_DMAMUX_H */

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1790068409.git.zhoubinbin@loongson.cn?part=1