linux-kernel - Re: [PATCH v4 2/4] dt-bindings: soc: spacemit: Add K1 MBUS controller

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] [day] [month] [year] [list]

Message-ID: <CAL_JsqKyXBaoYWrAsnyr6ytbvKMA3BaC=CmcgzgNtNvfabnEhg@mail.gmail.com>
Date: Tue, 27 May 2025 12:12:20 -0500
From: Rob Herring <robh@...nel.org>
To: Ze Huang <huangze@...t.edu.cn>
Cc: Krzysztof Kozlowski <krzk@...nel.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, Yixun Lan <dlan@...too.org>, 
	Thinh Nguyen <Thinh.Nguyen@...opsys.com>, Philipp Zabel <p.zabel@...gutronix.de>, 
	Paul Walmsley <paul.walmsley@...ive.com>, Palmer Dabbelt <palmer@...belt.com>, 
	Albert Ou <aou@...s.berkeley.edu>, Alexandre Ghiti <alex@...ti.fr>, linux-usb@...r.kernel.org, 
	devicetree@...r.kernel.org, linux-riscv@...ts.infradead.org, 
	spacemit@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 2/4] dt-bindings: soc: spacemit: Add K1 MBUS controller

On Tue, May 27, 2025 at 11:42 AM Ze Huang <huangze@...t.edu.cn> wrote:
>
> On 5/28/25 12:25 AM, Rob Herring wrote:
> > On Tue, May 27, 2025 at 07:13:05PM +0800, Ze Huang wrote:
> >> On Tue, May 27, 2025 at 08:51:19AM +0200, Krzysztof Kozlowski wrote:
> >>> On Mon, May 26, 2025 at 10:40:18PM GMT, Ze Huang wrote:
> >>>> Some devices on the SpacemiT K1 SoC perform DMA through a memory bus
> >>>> (MBUS) that is not their immediate parent in the device tree. This bus
> >>>> uses a different address mapping than the CPU.
> >>>>
> >>>> To express this topology properly, devices are expected to use the
> >>>> interconnects with name "dma-mem" to reference the MBUS controller.
> >>> I don't get it, sorry. Devices performing DMA through foo-bar should use
> >>> dmas property for foo-bar DMA controller. Interconnects is not for that.
> >>>
> >> Hi Krzysztof,
> >>
> >> Sorry for not clarifying this earlier - let me provide some context.
> >>
> >> The purpose of this node is to describe the address translation used for DMA
> >> device to memory transactions. I’m using the "interconnects" property with the
> >> reserved name "dma-mem" [1] in consumer devices to express this relationship.
> >> The actual translation is handled by the `of_translate_dma_address()` [2].
> >> This support was introduced in the series linked in [3].
> >>
> >> This setup is similar to what we see on platforms like Allwinner sun5i,
> >> sun8i-r40, and NVIDIA Tegra. [4][5]
> >>
> >> I considered reusing the existing Allwinner MBUS driver and bindings.
> >> However, the Allwinner MBUS includes additional functionality such as
> >> bandwidth monitoring and frequency control - features that are either
> >> absent or undocumented on the SpacemiT K1 SoC.
> > The interconnect binding is for when you have those software controls.
> > If you only have address translation, then 'dma-ranges' in a parent node
> > is all you need.
> >
> > Rob
>
> Different devices on the SoC may have distinct DMA address translations.
> A common dma-ranges in the parent node may not represent this accurately.

That is solved with different parent bus nodes which would be a more
accurate representation of the h/w. If the address translation is
different then, the devices have to be on different buses.

You can use interconnect binding, but you need to accurately describe
the interconnect provider.

Rob