linux-kernel - Re: [PATCH 01/10] dt-bindings: mtd: brcm,brcmnand: Drop "brcm,brcmnand" compatible for iProc

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] [day] [month] [year] [list]

Message-ID: <CAHi4H7HbJ6fZYzzXfnxo7jfncnuQ62C=2i0a8jxys8UeHhQ6Tw@mail.gmail.com>
Date: Wed, 14 Jan 2026 11:31:16 -0800
From: William Zhang <william.zhang@...adcom.com>
To: Rob Herring <robh@...nel.org>
Cc: Miquel Raynal <miquel.raynal@...tlin.com>, Richard Weinberger <richard@....at>, 
	Vignesh Raghavendra <vigneshr@...com>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Brian Norris <computersforpeace@...il.com>, Kamal Dasu <kdasu.kdev@...il.com>, 
	Nick Terrell <terrelln@...com>, David Sterba <dsterba@...e.com>, Rafał Miłecki <rafal@...ecki.pl>, 
	Simon Glass <sjg@...omium.org>, Linus Walleij <linusw@...nel.org>, 
	Ulf Hansson <ulf.hansson@...aro.org>, Marcus Folkesson <marcus.folkesson@...il.com>, 
	Tony Lindgren <tony@...mide.com>, Roger Quadros <rogerq@...nel.org>, Hauke Mehrtens <hauke@...ke-m.de>, 
	linux-mtd@...ts.infradead.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-mmc@...r.kernel.org
Subject: Re: [PATCH 01/10] dt-bindings: mtd: brcm,brcmnand: Drop
 "brcm,brcmnand" compatible for iProc

On Mon, Jan 12, 2026 at 7:48 AM Rob Herring <robh@...nel.org> wrote:
>
> On Fri, Jan 09, 2026 at 10:05:04AM -0800, William Zhang wrote:
> > Hi Rob,
> >
> > On Thu, Jan 8, 2026 at 9:53 AM Rob Herring (Arm) <robh@...nel.org> wrote:
> > >
> > > Some users of "brcm,nand-iproc" include "brcm,brcmnand" and some don't.
> > > The "brcm,brcmnand" compatible is not useful for iProc systems as
> > > there's a separate driver for iProc. So drop it as a fallback.
> > >
> > > Signed-off-by: Rob Herring (Arm) <robh@...nel.org>
> > > ---
> > >  Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml | 1 -
> > >  1 file changed, 1 deletion(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml
> > > index 064e840aeaa1..3105f8e6cbd6 100644
> > > --- a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml
> > > +++ b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml
> > > @@ -66,7 +66,6 @@ properties:
> > >          items:
> > >            - const: brcm,nand-iproc
> > >            - const: brcm,brcmnand-v6.1
> > > -          - const: brcm,brcmnand
> > >        - description: BCM63168 SoC-specific NAND controller
> > >          items:
> > >            - const: brcm,nand-bcm63168
> > >
> > > --
> > > 2.51.0
> > >
> >
> > Another fix would be adding brcm,brcmnand to the users of
> > brcm,nand-iproc to keep consistency with all other brcmnand chips and
> > utilize the fallback mechanism in the driver, although I agree it does
> > not happen in real life case.
> > I don't have any strong opinion either way but a follow-up change is
> > needed to remove the fallback from the brcm,nand-iproc dts files if we
> > go this route.
>
> The question to ask on a fallback is "is it usable on its own?". IOW,
> would a driver than only understands brcm,brcmnand function in this
> case. Given iproc needs its own driver and specific handling, the answer
> is no here.
>
> Plus, this matches what dts files actually have at least for the arm64
> ones.
>
> Rob

Fair enough.  With that,
Reviewed-by: William Zhang <william.zhang@...adcom.com>

Download attachment "smime.p7s" of type "application/pkcs7-signature" (5473 bytes)