linux-kernel - Re: [PATCH 09/18] dt-bindings: dma: ti: Add document for K3 BCDMA

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: <20201007154635.GA273523@bogus>
Date:   Wed, 7 Oct 2020 10:46:35 -0500
From:   Rob Herring <robh@...nel.org>
To:     Peter Ujfalusi <peter.ujfalusi@...com>
Cc:     vkoul@...nel.org, nm@...com, ssantosh@...nel.org, vigneshr@...com,
        dan.j.williams@...el.com, t-kristo@...com, lokeshvutla@...com,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org, dmaengine@...r.kernel.org
Subject: Re: [PATCH 09/18] dt-bindings: dma: ti: Add document for K3 BCDMA

On Wed, Oct 07, 2020 at 12:09:06PM +0300, Peter Ujfalusi wrote:
> 
> 
> On 06/10/2020 22.29, Rob Herring wrote:
> > On Wed, Sep 30, 2020 at 12:14:03PM +0300, Peter Ujfalusi wrote:
> >> New binding document for
> >> Texas Instruments K3 Block Copy DMA (BCDMA).
> >>
> >> BCDMA is introduced as part of AM64.
> >>
> 
> ...
> 
> > 
> >> +  ti,sci:
> >> +    description: phandle to TI-SCI compatible System controller node
> >> +    allOf:
> >> +      - $ref: /schemas/types.yaml#/definitions/phandle
> >> +
> >> +  ti,sci-dev-id:
> >> +    description: TI-SCI device id of BCDMA
> >> +    allOf:
> >> +      - $ref: /schemas/types.yaml#/definitions/uint32
> > 
> > We have a common definition for these.
> 
> Yes, in arm/keystone/ti,k3-sci-common.yaml, but I could not get to use
> that as reference.
> 
> I can not list it under the topmost allOf and drop the ti,sci and
> ti,sci-dev-id like this:
> 
> allOf:
>   - $ref: /schemas/dma/dma-controller.yaml#
>   - $ref: /schemas/arm/keystone/ti,k3-sci-common.yaml#
> 
> It results:
>   CHKDT   Documentation/devicetree/bindings/processed-schema-examples.json
>   DTEX    Documentation/devicetree/bindings/dma/ti/k3-bcdma.example.dts
>   SCHEMA  Documentation/devicetree/bindings/processed-schema-examples.json
>   DTC     Documentation/devicetree/bindings/dma/ti/k3-bcdma.example.dt.yaml
>   CHECK   Documentation/devicetree/bindings/dma/ti/k3-bcdma.example.dt.yaml
> Documentation/devicetree/bindings/dma/ti/k3-bcdma.example.dt.yaml:
> dma-controller@...c0100: 'ti,sci', 'ti,sci-dev-id' do not match any of
> the regexes: 'pinctrl-[0-9]+'
>         From schema: Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml
> 
> If I remove the "additionalProperties: false" from the schema file, then
> it compiles fine.

Yeah, you have to do 'unevaluatedProperties: false' which doesn't 
actually do anything yet, but can 'see' into $ref's.


> >> +  ti,asel:
> >> +    description: ASEL value for non slave channels
> >> +    allOf:
> > 
> > You no longer need 'allOf' here.
> 
> OK, I changed it in all instances.
> 
> > 
> >> +      - $ref: /schemas/types.yaml#/definitions/uint32
> >> +
> >> +  ti,sci-rm-range-bchan:
> >> +    description: |
> >> +      Array of BCDMA block-copy channel resource subtypes for resource
> >> +      allocation for this host
> >> +    allOf:
> >> +      - $ref: /schemas/types.yaml#/definitions/uint32-array
> >> +    minItems: 1
> >> +    # Should be enough
> >> +    maxItems: 255
> > 
> > Are there constraints for the individual elements?
> 
> In practice the subtype ID is 6bits number.
> Should I add limits to individual elements?

Yes:

items:
  maximum: 0x3f

> 
> >> +
> >> +  ti,sci-rm-range-tchan:
> >> +    description: |
> >> +      Array of BCDMA split tx channel resource subtypes for resource allocation
> >> +      for this host
> >> +    allOf:
> >> +      - $ref: /schemas/types.yaml#/definitions/uint32-array
> >> +    minItems: 1
> >> +    # Should be enough
> >> +    maxItems: 255
> >> +
> >> +  ti,sci-rm-range-rchan:
> >> +    description: |
> >> +      Array of BCDMA split rx channel resource subtypes for resource allocation
> >> +      for this host
> >> +    allOf:
> >> +      - $ref: /schemas/types.yaml#/definitions/uint32-array
> >> +    minItems: 1
> >> +    # Should be enough
> >> +    maxItems: 255
> >> +
> >> +required:
> >> +  - compatible
> >> +  - "#address-cells"
> >> +  - "#size-cells"
> >> +  - "#dma-cells"
> >> +  - reg
> >> +  - reg-names
> >> +  - msi-parent
> >> +  - ti,sci
> >> +  - ti,sci-dev-id
> >> +  - ti,sci-rm-range-bchan
> >> +  - ti,sci-rm-range-tchan
> >> +  - ti,sci-rm-range-rchan
> >> +
> >> +additionalProperties: false
> >> +
> >> +examples:
> >> +  - |+
> >> +    cbass_main {
> >> +        #address-cells = <2>;
> >> +        #size-cells = <2>;
> >> +
> >> +        main_dmss {
> >> +            compatible = "simple-mfd";
> > 
> > IMO, if it is memory-mapped, then you should be using 'simple-bus'.
> 
> We had the same discussion when I introduced the k3-udma binding and we
> have concluded on the simple-mfd as DMSS is not a bus, but contains
> different peripherals.

Ok.

Rob