linux-kernel - Re: [PATCH] dt-bindings: mtd: ti,gpmc-nand: Add missing 'rb-gpios'

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: <20211209133705.621912fe@xps13>
Date:   Thu, 9 Dec 2021 13:37:05 +0100
From:   Miquel Raynal <miquel.raynal@...tlin.com>
To:     Roger Quadros <rogerq@...nel.org>
Cc:     Rob Herring <robh@...nel.org>, Richard Weinberger <richard@....at>,
        Vignesh Raghavendra <vigneshr@...com>,
        Tony Lindgren <tony@...mide.com>, devicetree@...r.kernel.org,
        Thierry Reding <thierry.reding@...il.com>,
        linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] dt-bindings: mtd: ti,gpmc-nand: Add missing 'rb-gpios'

Hi Roger,

> >>>> With 'unevaluatedProperties' support implemented, the TI GPMC example
> >>>> has a warning:
> >>>>
> >>>> Documentation/devicetree/bindings/memory-controllers/ti,gpmc.example.dt.yaml: nand@0,0: Unevaluated properties are not allowed ('rb-gpios' was unexpected)
> >>>>
> >>>> Add the missing definition for 'rb-gpios'.    
> >>>
> >>> rb-gpios is already defined in nand-controller.yaml. I seems like the
> >>> real problem is that this file does not refer to it. Can you update the
> >>> fix?    
> >>
> >> I don't think we can refer to nand-controller.yaml right now as we are not
> >> fully compatible with it yet. Please see examples below.  
> > 
> > This is a *very* wrong way of defining a NAND setup. I will take the
> > patch to silence the warning, but please convert this representation to  
> 
> Thanks!
> 
> > the 'new' one. I believe on the driver side it should not be too
> > complicated to support having a few of these properties moved to a NAND
> > chip subnode and still support the below binding. Just be very clear
> > that if the legacy bindings are used, only a single chip is supported.  
> 
> I agree with you. It has been that way since ages. I will look at cleaning
> it up whenever possible for me. I think we will have to support the old
> bindings as well as the new one going forward as many legacy platforms
> are using it.

Yes of course, this is even a primary requirement.

Thanks,
Miquèl