linux-kernel - Re: [PATCH 1/5] dt-bindings: memory: fsl: convert ifc binding to yaml schema

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: <CADRPPNQ=32pzrLLqB+a_Ek6U8GcTeNDB18pRY_f2+JYcxDo0=Q@mail.gmail.com>
Date:   Fri, 8 Oct 2021 16:50:35 -0500
From:   Li Yang <leoyang.li@....com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>
Cc:     "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Shawn Guo <shawnguo@...nel.org>,
        "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 1/5] dt-bindings: memory: fsl: convert ifc binding to yaml schema

On Mon, Oct 4, 2021 at 4:32 AM Krzysztof Kozlowski
<krzysztof.kozlowski@...onical.com> wrote:
>
> On 01/10/2021 18:17, Li Yang wrote:
> > On Fri, Oct 1, 2021 at 5:01 AM Krzysztof Kozlowski
> > <krzysztof.kozlowski@...onical.com> wrote:
> >>
>
> (...)
>
> >>> +
> >>> +  interrupts:
> >>> +    minItems: 1
> >>> +    maxItems: 2
> >>> +    description: |
> >>> +      IFC may have one or two interrupts.  If two interrupt specifiers are
> >>> +      present, the first is the "common" interrupt (CM_EVTER_STAT), and the
> >>> +      second is the NAND interrupt (NAND_EVTER_STAT).  If there is only one,
> >>> +      that interrupt reports both types of event.
> >>> +
> >>> +  little-endian:
> >>> +    $ref: '/schemas/types.yaml#/definitions/flag'
> >>
> >> type: boolean
> >
> > It will not have a true or false value, but only present or not.  Is
> > the boolean type taking care of this too?
>
> boolean is for a property which does not accept values and true/false
> depends on its presence.
> See:
> Documentation/devicetree/bindings/phy/lantiq,vrx200-pcie-phy.yaml
> Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml

>From the dtschema/schemas/types.yaml file, flag type is defined as:
  flag:
    oneOf:
      - type: boolean
        const: true
      - type: 'null'

It looks like more than the boolean type itself.  But if the standard
boolean type is actually the same as the flag type we defined.
Shouldn't we remove the custom flag type then?

Regards,
Leo