linux-kernel - Re: [PATCH v22 17/18] dt-bindings: mtd: pl353-nand: Describe this hardware controller

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: <20210610023251.GA648931@robh.at.kernel.org>
Date:   Wed, 9 Jun 2021 21:32:51 -0500
From:   Rob Herring <robh@...nel.org>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>
Cc:     Miquel Raynal <miquel.raynal@...tlin.com>,
        Richard Weinberger <richard@....at>,
        Vignesh Raghavendra <vigneshr@...com>,
        Tudor Ambarus <Tudor.Ambarus@...rochip.com>,
        linux-mtd@...ts.infradead.org, devicetree@...r.kernel.org,
        Michal Simek <monstr@...str.eu>,
        Naga Sureshkumar Relli <nagasure@...inx.com>,
        Amit Kumar Mahapatra <akumarma@...inx.com>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        helmut.grohne@...enta.de, Srinivas Goud <sgoud@...inx.com>,
        Siva Durga Prasad Paladugu <sivadur@...inx.com>
Subject: Re: [PATCH v22 17/18] dt-bindings: mtd: pl353-nand: Describe this
 hardware controller

On Wed, Jun 09, 2021 at 03:57:05PM +0200, Krzysztof Kozlowski wrote:
> On 09/06/2021 15:36, Miquel Raynal wrote:
> > Hi Krzysztof,
> > 
> > Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com> wrote on Wed, 9
> > Jun 2021 14:01:10 +0200:
> > 
> >> On 09/06/2021 10:01, Miquel Raynal wrote:
> >>> Add a yaml description of this NAND controller which is described as a
> >>> subnode of the SMC bus.
> >>>
> >>> Signed-off-by: Miquel Raynal <miquel.raynal@...tlin.com>
> >>> ---
> >>>  .../bindings/mtd/arm,pl353-nand-r2p1.yaml     | 57 +++++++++++++++++++
> >>>  1 file changed, 57 insertions(+)
> >>>  create mode 100644 Documentation/devicetree/bindings/mtd/arm,pl353-nand-r2p1.yaml
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/mtd/arm,pl353-nand-r2p1.yaml b/Documentation/devicetree/bindings/mtd/arm,pl353-nand-r2p1.yaml
> >>> new file mode 100644
> >>> index 000000000000..e72fa14b4385
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/mtd/arm,pl353-nand-r2p1.yaml
> >>> @@ -0,0 +1,57 @@
> >>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> >>> +%YAML 1.2
> >>> +---
> >>> +$id: http://devicetree.org/schemas/mtd/arm,pl353-nand-r2p1.yaml#
> >>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >>> +
> >>> +title: PL353 NAND Controller device tree bindings
> >>> +
> >>> +allOf:
> >>> +  - $ref: "nand-controller.yaml"
> >>> +
> >>> +maintainers:
> >>> +  - Miquel Raynal <miquel.raynal@...tlin.com>
> >>> +  - Naga Sureshkumar Relli <naga.sureshkumar.relli@...inx.com>
> >>> +
> >>> +properties:
> >>> +  compatible:
> >>> +    items:
> >>> +      - enum:  
> >>
> >> That's not an enum, but simple const without items.
> > 
> > Ok.
> > 
> >>
> >>> +          - arm,pl353-nand-r2p1
> >>> +
> >>> +  reg:
> >>> +    items:
> >>> +      - items:
> >>> +          - description: CS with regard to the parent ranges property
> >>> +          - description: Offset of the memory region requested by the device
> >>> +          - description: Length of the memory region requested by the device  
> >>
> >> Doesn't it depend on parent's address/size cells?
> > 
> > Yes, but as the child nodes are not defined in the parent's binding
> > (ie. the SMC) I think it's interesting to have them defined here, no?
> 
> The trouble is if parent decides to have different address/size cells.
> The schema will stop matching. I am actually not that sure if such case
> is real since the pl353 NAND part will usually be connected to pl353
> SMC. However the schema now hard-codes specific dependency against
> parent schema/node.
> 
> Rob,
> Maybe you have here some thoughts?

I think it is fine given the parent child coupling.

Rob