linux-kernel - Re: [PATCH v5 1/3] dt-bindings: dmaengine: Add dmamux for CV18XX/SG200X series SoC

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:
 <IA1PR20MB4953EDEEFC3128741F8E152EBB352@IA1PR20MB4953.namprd20.prod.outlook.com>
Date: Tue, 26 Mar 2024 15:35:57 +0800
From: Inochi Amaoto <inochiama@...look.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>, 
	Inochi Amaoto <inochiama@...look.com>, Vinod Koul <vkoul@...nel.org>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>, Conor Dooley <conor+dt@...nel.org>, 
	Chen Wang <unicorn_wang@...look.com>, Paul Walmsley <paul.walmsley@...ive.com>, 
	Palmer Dabbelt <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>
Cc: Jisheng Zhang <jszhang@...nel.org>, Liu Gui <kenneth.liu@...hgo.com>, 
	Jingbao Qiu <qiujingbao.dlmu@...il.com>, dlan@...too.org, dmaengine@...r.kernel.org, 
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org
Subject: Re: [PATCH v5 1/3] dt-bindings: dmaengine: Add dmamux for
 CV18XX/SG200X series SoC

On Tue, Mar 26, 2024 at 07:57:44AM +0100, Krzysztof Kozlowski wrote:
> On 26/03/2024 02:47, Inochi Amaoto wrote:
> > The DMA IP of Sophgo CV18XX/SG200X is based on a DW AXI CORE, with
> > an additional channel remap register located in the top system control
> > area. The DMA channel is exclusive to each core.
> > 
> > Add the dmamux binding for CV18XX/SG200X series SoC
> > 
> 
> 
> > +
> > +allOf:
> > +  - $ref: dma-router.yaml#
> > +
> > +properties:
> > +  compatible:
> > +    const: sophgo,cv1800-dmamux
> > +
> > +  reg:
> > +    items:
> > +      - description: DMA channal remapping register
> > +      - description: DMA channel interrupt mapping register
> > +
> > +  '#dma-cells':
> > +    const: 2
> > +    description:
> > +      The first cells is device id. The second one is the cpu id.
> > +
> > +  dma-masters:
> > +    maxItems: 1
> > +
> > +  dma-requests:
> > +    const: 8
> 
> If this is const, why do you need it in the DTS in the first place?
> compatible defines it.
> 

Yes, you are right. I will remove this property.

> > +
> > +required:
> > +  - '#dma-cells'
> > +  - dma-masters
> > +
> 
> 
> I don't understand what happened here. Previously you had a child and I
> proposed to properly describe it with $ref.
> 
> Now, all children are gone. Binding is supposed to be complete. Based on
> your cover letter, this is not complete, but why? What is missing and
> why it cannot be added?
> 

The binding of syscon is removed due to a usb phy subdevices, which needs 
sometime to figure out the actual property. This is why the syscon binding 
is removed.

I think it is better to use the origianl syscon series to evolve after
the usb phy binding is submitted. The subdevices of syscon may need
much reverse engineering to know its parameters. So at least for now,
the syscon binding is hard to be complete.

> 
> > +additionalProperties: false
> > +
> > +examples:
> > +  - |
> > +    dma-router {
> > +      compatible = "sophgo,cv1800-dmamux";
> > +      #dma-cells = <2>;
> > +      dma-masters = <&dmac>;
> > +      dma-requests = <8>;
> > +    };
> > diff --git a/include/dt-bindings/dma/cv1800-dma.h b/include/dt-bindings/dma/cv1800-dma.h
> > new file mode 100644
> > index 000000000000..3ce9dac25259
> > --- /dev/null
> > +++ b/include/dt-bindings/dma/cv1800-dma.h
> 
> Filename should match bindings filename.
> 

Thanks.

> 
> Anyway, the problem is that it is a dead header. I don't see it being
> used, so it is not a binding.
> 

This header is not used because the dmamux node is not defined at now.
And considering the limitation of this dmamux, maybe only devices that 
require dma as a must can have the dma assigned. 
Due to the fact, I think it may be a long time to wait for this header
to be used as the binding header.

> 
> 
> Best regards,
> Krzysztof
>