linux-kernel - Re: [PATCH 2/2] rockchip: dts: Enable UART DMA by adding default dma-names property

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4007782.fW5hKsROvD@diego>
Date: Wed, 17 Sep 2025 16:25:59 +0200
From: Heiko Stübner <heiko@...ech.de>
To: Ed Wildgoose <lists@...dgooses.com>, Dragan Simic <dsimic@...jaro.org>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, devicetree@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-rockchip@...ts.infradead.org,
 linux-kernel@...r.kernel.org
Subject:
 Re: [PATCH 2/2] rockchip: dts: Enable UART DMA by adding default dma-names
 property

Am Mittwoch, 17. September 2025, 14:22:52 Mitteleuropäische Sommerzeit schrieb Dragan Simic:
> Hello Ed,
> 
> On 2025-09-17 13:49, Ed Wildgoose wrote:
> > Kernel appears to need a dma-names set for DMA to actually enable. Set 
> > a
> > default dma-names property for all UARTs defined in the base 
> > rk356x-base
> > dtsi
> > 
> > This is tested on a Radxa Zero 3W (which has 5x UARTs) and removes the
> > warnings and enables DMA on this platform
> 
> Thanks for the patches.
> 
> We should (still) stay away from defining the "dma-names" property
> at the SoC level, because doing that causes serious issues in certain
> cases.  Thus, I'd suggest that this patch is dropped, and that the
> "dma-names" property is defined instead at the board level, where
> it's needed and tested to work as expected.
> 
> Please see commit bf6f26deb0e8 (arm64: dts: rockchip: Add dma-names
> to uart1 on quartz64-b, 2024-06-28) for further explanation.
> 
> If/when the underlying issues are debugged and resolved, we can get
> back to defining the "dma-names" property at the SoC level.

And apart from the whole stability thing, on a number of socs the pl330
dma controller has more possible sources for dma operations than it
has available channels ... and right now the driver does not support
handling this.

So you can (and if I remember correctly we did) end up with some uart
requesting dma channels (and not needing them) and then sound not
getting any.


Heiko