[PATCH v2 3/7] dt-bindings: dmaengine: Add SpacemiT K3 DMA request definitions

[Krzysztof Kozlowski]

On 28/03/2026 10:58, Troy Mitchell wrote:
> On Fri Mar 27, 2026 at 3:30 PM CST, Krzysztof Kozlowski wrote:
>> On Thu, Mar 26, 2026 at 04:17:18PM +0800, Troy Mitchell wrote:
>>> From: liyeshan <yeshan.li at spacemit.com>
>>>
>>> Add device tree binding header for SpacemiT k3 DMA request numbers. This
>>
>> Why?
> The DMA request mappings are hardware-hardwired and differ between the K1 and K3 SoCs.
> Therefore, separate header files are required to define these unique constants for each
> platform to ensure correct DMA channel allocation in the device tree.

Nothing explains why we want this as ABI. Header does not ensure correct
DMA channel allocation.


>>
>>> defines the DMA request mapping for non-secure peripherals including UART,
>>> I2C, SSP/SPI, CAN, and QSPI.
>>>
>>> Signed-off-by: liyeshan <yeshan.li at spacemit.com>
>>
>> Name looks close to login name?
> I will contact her and confirm.
>>
>>> Signed-off-by: Guodong Xu <guodong at riscstar.com>
>>> Signed-off-by: Troy Mitchell <troy.mitchell at linux.spacemit.com>
>>> ---
>>>  include/dt-bindings/dma/k3-pdma.h | 83 +++++++++++++++++++++++++++++++++++++++
>>
>> I am already confused what is happening in this patchset - so which
>> device are you adding? K1 or K3?
> Aside from this K1-related patch, the rest of the series focuses on adding support for
> the K3 SoC. I included the K1 header because I noticed it was missing in the upstream
> tree while working on the K3 support.

So k3 is the new device? Then this is not a separate commit, but belongs
to the bindings patch.

> 
> It seems my attempt to 'clean up' K1 while adding K3 has caused unnecessary confusion.
> Would you prefer me to remove the K1 patch from this series and submit it as a separate
> patch?

I expect explaining in commit msg why you are doing things.

So far none of these are bindings, so drop both headers from bindings.
Feel free to provide explanation what part of Linux SW you are binding here.

Best regards,
Krzysztof