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

Message-ID: <20260112154805.GA271138-robh@kernel.org>
Date: Mon, 12 Jan 2026 09:48:05 -0600
From: Rob Herring <robh@...nel.org>
To: William Zhang <william.zhang@...adcom.com>
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 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