linux-kernel - Re: [PATCH v2 1/8] dt-bindings: dma: marvell,mmp-dma: Add SpacemiT K1 PDMA support

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: <43f19fbc-838b-431e-9d02-ecacf5f43731@kernel.org>
Date: Wed, 2 Jul 2025 22:38:00 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Guodong Xu <guodong@...cstar.com>
Cc: Vinod Koul <vkoul@...nel.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Yixun Lan <dlan@...too.org>,
 Duje Mihanović <duje.mihanovic@...le.hr>,
 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>, Alex Elder <elder@...cstar.com>,
 Vivian Wang <wangruikang@...as.ac.cn>, dmaengine@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-riscv@...ts.infradead.org, spacemit@...ts.linux.dev
Subject: Re: [PATCH v2 1/8] dt-bindings: dma: marvell,mmp-dma: Add SpacemiT K1
 PDMA support

On 01/07/2025 11:52, Guodong Xu wrote:
> Hi, Krzysztof
> 
> On Tue, Jul 1, 2025 at 3:35 PM Krzysztof Kozlowski <krzk@...nel.org> wrote:
>>
>> On 01/07/2025 07:36, Guodong Xu wrote:
>>> Add "spacemit,k1-pdma" compatible string to support SpacemiT K1 PDMA
>>> controller. This variant requires:
>>
>> Why is this marvell? This should be explained here, it's really unexpected.
>>
> 
> SpacemiT K1 SoC uses the same DMA controller as Marvell MMP. They share most
> of the registers (and address offsets) and only enhanced in addressing space
> capability (from 32bit to 64bit).

I hope you got the last comment...

> 
> Also, spacemit,k1-pdma and marvell,pdma-1.0 use the same driver (mmp_pdma.c),
> that's the reason why I chose keeping them in the same binding file.

That's moderate reason. I explained here further - don't grow old
bindings with completely new devices, because you keep growing old,
poorer patterns. You have a new device, you can make it right.


...

>>> +      properties:
>>> +        compatible:
>>> +          contains:
>>> +            const: spacemit,k1-pdma
>>> +    then:
>>> +      required:
>>> +        - clocks
>>> +        - resets
>>> +    else:
>>> +      properties:
>>> +        clocks: false
>>> +        resets: false
>>> +  - if:
>>> +      properties:
>>> +        compatible:
>>> +          contains:
>>> +            enum:
>>> +              - marvell,pdma-1.0
>>> +              - spacemit,k1-pdma
>>> +    then:
>>> +      properties:
>>> +        '#dma-cells':
>>> +          const: 2
>>> +          description:
>>> +            The first cell contains the DMA request number for the peripheral
>>> +            device. The second cell is currently unused but must be present for
>>> +            backward compatibility.
>>> +    else:
>>> +      properties:
>>> +        '#dma-cells':
>>> +          const: 1
>>> +          description:
>>> +            The cell contains the DMA request number for the peripheral device.
>>
>>
>> It's getting complicated. I suggest to make your own schema. Then you
>> would also switch to preferred 'sram' property instead of that legacy
>> 'asram'.
>>
>> Really, ancient schemas should not be grown for new, completely
> 
> The reason that they share the same device driver may not be strong enough
> compared to what you said here.

If DMA maintainer(s) reject complexity in driver, then it is fine. But
till that happens, you should rather come with a clean new binding and
don't grow legacy.


Best regards,
Krzysztof