linux-kernel - Re: [PATCH v2 6/6] dt-bindings: dma: Convert Qualcomm BAM DMA binding to json format

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]

Date:   Tue, 12 Apr 2022 11:49:53 +0530
From:   Kuldeep Singh <singh.kuldeep87k@...il.com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
Cc:     Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Vinod Koul <vkoul@...nel.org>, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        dmaengine@...r.kernel.org
Subject: Re: [PATCH v2 6/6] dt-bindings: dma: Convert Qualcomm BAM DMA
 binding to json format

On Mon, Apr 11, 2022 at 01:38:41PM +0200, Krzysztof Kozlowski wrote:
> On 11/04/2022 12:58, Kuldeep Singh wrote:
> >> This is something new and it seems only one SoC defines it (not even one
> >> BAM version). I wonder whether this is actually correct or this
> >> particular version of BAM is slightly different. Maybe someone could
> >> clarify it, but if no - looks ok.
> > 
> > Yes, sdm845.dtsi uses 4 entries and rest 1.
> 
> Yes, I know. This does not solve my wonder.
> 
> > 
> >>
> >>> +
> >>> +  num-channels:
> >>> +    $ref: /schemas/types.yaml#/definitions/uint32
> >>> +    description:
> >>> +      Indicates supported number of DMA channels in a remotely controlled bam.
> >>> +
> >>> +  qcom,controlled-remotely:
> >>> +    $ref: /schemas/types.yaml#/definitions/flag
> >>
> >> type: boolean
> > 
> > Boolean comes under flag in types.yaml
> > 
> > definitions:
> >   flag:
> >     oneOf:
> >       - type: boolean
> >         const: true
> >       - type: 'null'
> > 
> > I have seen other boolean properties(spi-cpol, spi-cpha and bunch of
> > others) using type flag. I think we should keep flag here.
> 
> type:boolean is just shorter and example-schema recommends it. If you
> want to base on something (as a template, pattern) then the
> example-schema is the source, the preferred one.

I had seen other spec using flag and that's why kept same here.
Which example schema are you talking about?

> >>
> >> clocks, clock-names, qcom-ee - these are required according to old bindings.
> > 
> > I missed qcom,ee. Will add in v3.
> > 
> > For clocks and clock-names , there are two platforms(msm8996.dtsi,
> > sdm845.dtsi) where these properties are missing. And I don't want to add
> > some random values. Shall I skip them here? and let board owners add
> > them later.
> 
> These are required, so the SoC DTSI should be fixed. Not with random
> clocks but something proper. :)

Yes absolutely :-)
I have kept Srinivas in copy, who sent initial support for both the
dtsi. Probably he can confirm provided his email doesn't bounce.

Anyway Krzysztof, can you confirm the same as you have been actively
contributing to Qcom peripherals. I will add credit in follow-up
submission.