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 for Android: free password hash cracker in your pocket

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

Message-ID: <d855eedf-099f-4396-a79b-ee51b3bf24cb@whut.edu.cn>
Date: Wed, 28 May 2025 00:41:56 +0800
From: Ze Huang <huangze@...t.edu.cn>
To: Rob Herring <robh@...nel.org>
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 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.