[PATCH v2 0/4] NAND support for Broadcom NS2 SoC

[PATCH v2 0/4] NAND support for Broadcom NS2 SoC

[Anup Patel]

We enable NAND support for Broadcom NS2 SoC by reusing existing
BRCMNAND driver.

This patchset applies on-top of "arm64: Simple additions to
NS2 DT" v1 patchset and is available in ns2_nand_v2 branch of
https://github.com/Broadcom/arm64-linux.git.

The patchset is tested on NS2 SVK.

Changes since v1:
 - Dropped patch3 and patch4 because we don't need to reset
   BRCMNAND controller for NS2.
 - Added patch to force 8bit mode before doing nand_scan_ident()
   in brcmnand_init_cs().

Anup Patel (4):
  mtd: brcmnand: Fix pointer type-cast in brcmnand_write()
  mtd: nand: Allow MTD_NAND_BRCMNAND to be selected for ARM64
  mtd: brcmnand: Force 8bit mode before doing nand_scan_ident()
  arm64: dts: Add BRCM IPROC NAND DT node for NS2

 arch/arm64/boot/dts/broadcom/ns2-svk.dts | 12 ++++++++++++
 arch/arm64/boot/dts/broadcom/ns2.dtsi    | 14 ++++++++++++++
 drivers/mtd/nand/Kconfig                 |  2 +-
 drivers/mtd/nand/brcmnand/brcmnand.c     | 13 +++++++++++--
 4 files changed, 38 insertions(+), 3 deletions(-)

-- 
1.9.1

[PATCH v2 1/4] mtd: brcmnand: Fix pointer type-cast in brcmnand_write()

[Anup Patel]

We should always type-cast pointer to "long" or "unsigned long"
because size of pointer is same as machine word size. This will
avoid pointer type-cast issues on both 32bit and 64bit systems.

This patch fixes pointer type-cast issue in brcmnand_write()
as-per above info.

Signed-off-by: Anup Patel <anup.patel@broadcom.com>
Reviewed-by: Vikram Prakash <vikramp@broadcom.com>
Reviewed-by: Ray Jui <rjui@broadcom.com>
Reviewed-by: Scott Branden <sbranden@broadcom.com>
---
 drivers/mtd/nand/brcmnand/brcmnand.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c b/drivers/mtd/nand/brcmnand/brcmnand.c
index fddb795..4cba03d 100644
--- a/drivers/mtd/nand/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/brcmnand/brcmnand.c
@@ -1544,9 +1544,9 @@ static int brcmnand_write(struct mtd_info *mtd, struct nand_chip *chip,
 
 	dev_dbg(ctrl->dev, "write %llx <- %p\n", (unsigned long long)addr, buf);
 
-	if (unlikely((u32)buf & 0x03)) {
+	if (unlikely((unsigned long)buf & 0x03)) {
 		dev_warn(ctrl->dev, "unaligned buffer: %p\n", buf);
-		buf = (u32 *)((u32)buf & ~0x03);
+		buf = (u32 *)((unsigned long)buf & ~0x03);
 	}
 
 	brcmnand_wp(mtd, 0);
-- 
1.9.1

[PATCH v2 1/4] mtd: brcmnand: Fix pointer type-cast in brcmnand_write()

[Ray Jui]

Correct me if I remember it wrong, but I thought this patch has already
been merged by Brian?

Thanks,

Ray

On 10/16/2015 2:08 AM, Anup Patel wrote:
> We should always type-cast pointer to "long" or "unsigned long"
> because size of pointer is same as machine word size. This will
> avoid pointer type-cast issues on both 32bit and 64bit systems.
> 
> This patch fixes pointer type-cast issue in brcmnand_write()
> as-per above info.
> 
> Signed-off-by: Anup Patel <anup.patel@broadcom.com>
> Reviewed-by: Vikram Prakash <vikramp@broadcom.com>
> Reviewed-by: Ray Jui <rjui@broadcom.com>
> Reviewed-by: Scott Branden <sbranden@broadcom.com>
> ---
>  drivers/mtd/nand/brcmnand/brcmnand.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c b/drivers/mtd/nand/brcmnand/brcmnand.c
> index fddb795..4cba03d 100644
> --- a/drivers/mtd/nand/brcmnand/brcmnand.c
> +++ b/drivers/mtd/nand/brcmnand/brcmnand.c
> @@ -1544,9 +1544,9 @@ static int brcmnand_write(struct mtd_info *mtd, struct nand_chip *chip,
>  
>  	dev_dbg(ctrl->dev, "write %llx <- %p\n", (unsigned long long)addr, buf);
>  
> -	if (unlikely((u32)buf & 0x03)) {
> +	if (unlikely((unsigned long)buf & 0x03)) {
>  		dev_warn(ctrl->dev, "unaligned buffer: %p\n", buf);
> -		buf = (u32 *)((u32)buf & ~0x03);
> +		buf = (u32 *)((unsigned long)buf & ~0x03);
>  	}
>  
>  	brcmnand_wp(mtd, 0);
> 

[PATCH v2 1/4] mtd: brcmnand: Fix pointer type-cast in brcmnand_write()

[Brian Norris]

On Fri, Oct 16, 2015 at 08:36:22AM -0700, Ray Jui wrote:
> Correct me if I remember it wrong, but I thought this patch has already
> been merged by Brian?

You are correct.

Anup,

Please base MTD patches on the MTD development tree (i.e., l2-mtd.git):

http://linux-mtd.infradead.org/source.html

(In this case it's no problem; I'll just ignore the first two patches.)

Brian

[PATCH v2 1/4] mtd: brcmnand: Fix pointer type-cast in brcmnand_write()

[Anup Patel]

> -----Original Message-----
> From: Ray Jui [mailto:rjui at broadcom.com]
> Sent: 16 October 2015 21:06
> To: Anup Patel; David Woodhouse; Brian Norris; linux-mtd at lists.infradead.org
> Cc: Rob Herring; Pawel Moll; Mark Rutland; Ian Campbell; Kumar Gala; Catalin
> Marinas; Will Deacon; Scott Branden; Florian Fainelli; Pramod Kumar; Vikram
> Prakash; Sandeep Tripathy; linux-arm-kernel at lists.infradead.org;
> devicetree at vger.kernel.org; linux-kernel at vger.kernel.org; bcm-kernel-
> feedback-list
> Subject: Re: [PATCH v2 1/4] mtd: brcmnand: Fix pointer type-cast in
> brcmnand_write()
> 
> Correct me if I remember it wrong, but I thought this patch has already been
> merged by Brian?

Yes, patch1 and patch2 were merged by Brian. I realized this after I had
send-out v2. Anyways we can ignore patch1 and patch2 from this patchset
because they are same as v1.

Regards,
Anup

[PATCH v2 2/4] mtd: nand: Allow MTD_NAND_BRCMNAND to be selected for ARM64

[Anup Patel]

The BRCM NAND driver can be re-used for Broadcom ARM64 SoCs hence
this patch updates Kconfig to allow selection of MTD_NAND_BRCMNAND
for ARM64.

Signed-off-by: Anup Patel <anup.patel@broadcom.com>
Reviewed-by: Vikram Prakash <vikramp@broadcom.com>
Reviewed-by: Ray Jui <rjui@broadcom.com>
Reviewed-by: Pramod KUMAR <pramodku@broadcom.com>
Reviewed-by: Scott Branden <sbranden@broadcom.com>
---
 drivers/mtd/nand/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 3324281..a1b5819 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -393,7 +393,7 @@ config MTD_NAND_GPMI_NAND
 
 config MTD_NAND_BRCMNAND
 	tristate "Broadcom STB NAND controller"
-	depends on ARM || MIPS
+	depends on ARM || ARM64 || MIPS
 	help
 	  Enables the Broadcom NAND controller driver. The controller was
 	  originally designed for Set-Top Box but is used on various BCM7xxx,
-- 
1.9.1

[PATCH v2 2/4] mtd: nand: Allow MTD_NAND_BRCMNAND to be selected for ARM64

[Ray Jui]

This patch is the same. I thought it has already been merged by Brian?

On 10/16/2015 2:08 AM, Anup Patel wrote:
> The BRCM NAND driver can be re-used for Broadcom ARM64 SoCs hence
> this patch updates Kconfig to allow selection of MTD_NAND_BRCMNAND
> for ARM64.
> 
> Signed-off-by: Anup Patel <anup.patel@broadcom.com>
> Reviewed-by: Vikram Prakash <vikramp@broadcom.com>
> Reviewed-by: Ray Jui <rjui@broadcom.com>
> Reviewed-by: Pramod KUMAR <pramodku@broadcom.com>
> Reviewed-by: Scott Branden <sbranden@broadcom.com>
> ---
>  drivers/mtd/nand/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
> index 3324281..a1b5819 100644
> --- a/drivers/mtd/nand/Kconfig
> +++ b/drivers/mtd/nand/Kconfig
> @@ -393,7 +393,7 @@ config MTD_NAND_GPMI_NAND
>  
>  config MTD_NAND_BRCMNAND
>  	tristate "Broadcom STB NAND controller"
> -	depends on ARM || MIPS
> +	depends on ARM || ARM64 || MIPS
>  	help
>  	  Enables the Broadcom NAND controller driver. The controller was
>  	  originally designed for Set-Top Box but is used on various BCM7xxx,
> 

[PATCH v2 2/4] mtd: nand: Allow MTD_NAND_BRCMNAND to be selected for ARM64

[Brian Norris]

On Fri, Oct 16, 2015 at 08:36:58AM -0700, Ray Jui wrote:
> This patch is the same. I thought it has already been merged by Brian?

Right as well. I'll ignore this one.

Brian

[PATCH v2 2/4] mtd: nand: Allow MTD_NAND_BRCMNAND to be selected for ARM64

[Arnd Bergmann]

On Friday 16 October 2015 14:38:55 Anup Patel wrote:
> 
> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
> index 3324281..a1b5819 100644
> --- a/drivers/mtd/nand/Kconfig
> +++ b/drivers/mtd/nand/Kconfig
> @@ -393,7 +393,7 @@ config MTD_NAND_GPMI_NAND
>  
>  config MTD_NAND_BRCMNAND
>         tristate "Broadcom STB NAND controller"
> -       depends on ARM || MIPS
> +       depends on ARM || ARM64 || MIPS
>         help
>           Enables the Broadcom NAND controller driver. The controller was
>           originally designed for Set-Top Box but is used on various BCM7xxx,
> -- 
> 

I think you also need this one:

8<-----------
>From 0ab7b2d32921b3f3da15274d8c3982ba1d54660f Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@arndb.de>
Date: Thu, 4 Jun 2015 09:25:59 +0200
Subject: [PATCH] mtd: brcmnand depends on MTD_NAND

MTD_NAND_BRCMNAND uses the generic nand functions, but is currently allowed
to be built without CONFIG_MTD_NAND, which results in a link error:

drivers/built-in.o: In function `brcmnand_remove':
coresight-replicator.c:(.text+0x17ae6c): undefined reference to `nand_release'
drivers/built-in.o: In function `brcmnand_probe':
coresight-replicator.c:(.text+0x17d4b4): undefined reference to `nand_scan_ident'
coresight-replicator.c:(.text+0x17d948): undefined reference to `nand_scan_tail'

This adds an explicit Kconfig dependency.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 289664089cf3..4b7e853ce35d 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -393,6 +393,7 @@ config MTD_NAND_GPMI_NAND
 
 config MTD_NAND_BRCMNAND
 	tristate "Broadcom STB NAND controller"
+	depends on MTD_NAND
 	depends on ARM || ARM64 || MIPS
 	help
 	  Enables the Broadcom NAND controller driver. The controller was

[PATCH v2 2/4] mtd: nand: Allow MTD_NAND_BRCMNAND to be selected for ARM64

[Brian Norris]

On Fri, Oct 16, 2015 at 06:24:21PM +0200, Arnd Bergmann wrote:
> I think you also need this one:

Are you sure?

> 8<-----------
> From 0ab7b2d32921b3f3da15274d8c3982ba1d54660f Mon Sep 17 00:00:00 2001
> From: Arnd Bergmann <arnd@arndb.de>
> Date: Thu, 4 Jun 2015 09:25:59 +0200
> Subject: [PATCH] mtd: brcmnand depends on MTD_NAND
> 
> MTD_NAND_BRCMNAND uses the generic nand functions, but is currently allowed
> to be built without CONFIG_MTD_NAND, which results in a link error:
> 
> drivers/built-in.o: In function `brcmnand_remove':
> coresight-replicator.c:(.text+0x17ae6c): undefined reference to `nand_release'
> drivers/built-in.o: In function `brcmnand_probe':
> coresight-replicator.c:(.text+0x17d4b4): undefined reference to `nand_scan_ident'
> coresight-replicator.c:(.text+0x17d948): undefined reference to `nand_scan_tail'

How did you get this? MTD_NAND_BRCMNAND is surrounded in the
'if MTD_NAND' block, which implicitly generates a MTD_NAND dependency.
And I can confirm that in menuconfig, I see this when I disable MTD_NAND
and search for BRCMNAND:

   Symbol: MTD_NAND_BRCMNAND [=n]
   Type  : tristate
   Prompt: Broadcom STB NAND controller
     Location:
       -> Device Drivers
         -> Memory Technology Device (MTD) support (MTD [=y])
   (1)     -> NAND Device Support (MTD_NAND [=n])
     Defined at drivers/mtd/nand/Kconfig:394
     Depends on: MTD [=y] && MTD_NAND [=n] && (ARM [=y] || ARM64 || MIPS)

Brian

> This adds an explicit Kconfig dependency.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> 
> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
> index 289664089cf3..4b7e853ce35d 100644
> --- a/drivers/mtd/nand/Kconfig
> +++ b/drivers/mtd/nand/Kconfig
> @@ -393,6 +393,7 @@ config MTD_NAND_GPMI_NAND
>  
>  config MTD_NAND_BRCMNAND
>  	tristate "Broadcom STB NAND controller"
> +	depends on MTD_NAND
>  	depends on ARM || ARM64 || MIPS
>  	help
>  	  Enables the Broadcom NAND controller driver. The controller was
> 

[PATCH v2 2/4] mtd: nand: Allow MTD_NAND_BRCMNAND to be selected for ARM64

[Arnd Bergmann]

On Friday 16 October 2015 09:54:45 Brian Norris wrote:
> > MTD_NAND_BRCMNAND uses the generic nand functions, but is currently allowed
> > to be built without CONFIG_MTD_NAND, which results in a link error:
> > 
> > drivers/built-in.o: In function `brcmnand_remove':
> > coresight-replicator.c:(.text+0x17ae6c): undefined reference to `nand_release'
> > drivers/built-in.o: In function `brcmnand_probe':
> > coresight-replicator.c:(.text+0x17d4b4): undefined reference to `nand_scan_ident'
> > coresight-replicator.c:(.text+0x17d948): undefined reference to `nand_scan_tail'
> 
> How did you get this? MTD_NAND_BRCMNAND is surrounded in the
> 'if MTD_NAND' block, which implicitly generates a MTD_NAND dependency.
> And I can confirm that in menuconfig, I see this when I disable MTD_NAND
> and search for BRCMNAND:
> 
>    Symbol: MTD_NAND_BRCMNAND [=n]
>    Type  : tristate
>    Prompt: Broadcom STB NAND controller
>      Location:
>        -> Device Drivers
>          -> Memory Technology Device (MTD) support (MTD [=y])
>    (1)     -> NAND Device Support (MTD_NAND [=n])
>      Defined at drivers/mtd/nand/Kconfig:394
>      Depends on: MTD [=y] && MTD_NAND [=n] && (ARM [=y] || ARM64 || MIPS)

Sorry, can't reproduce it any more. My patch is dated June 4, so it was
probably broken then but got fixed since. I normally try to verify that
the patches are still needed before I send them, but this time I only
saw the current discussion and remembered something vague about it
and sent what I had in my backlog of the randconfig-fixes series.

Sorry for the confusion.

	Arnd

[PATCH v2 2/4] mtd: nand: Allow MTD_NAND_BRCMNAND to be selected for ARM64

[Florian Fainelli]

On 16/10/15 12:25, Arnd Bergmann wrote:
> On Friday 16 October 2015 09:54:45 Brian Norris wrote:
>>> MTD_NAND_BRCMNAND uses the generic nand functions, but is currently allowed
>>> to be built without CONFIG_MTD_NAND, which results in a link error:
>>>
>>> drivers/built-in.o: In function `brcmnand_remove':
>>> coresight-replicator.c:(.text+0x17ae6c): undefined reference to `nand_release'
>>> drivers/built-in.o: In function `brcmnand_probe':
>>> coresight-replicator.c:(.text+0x17d4b4): undefined reference to `nand_scan_ident'
>>> coresight-replicator.c:(.text+0x17d948): undefined reference to `nand_scan_tail'
>>
>> How did you get this? MTD_NAND_BRCMNAND is surrounded in the
>> 'if MTD_NAND' block, which implicitly generates a MTD_NAND dependency.
>> And I can confirm that in menuconfig, I see this when I disable MTD_NAND
>> and search for BRCMNAND:
>>
>>    Symbol: MTD_NAND_BRCMNAND [=n]
>>    Type  : tristate
>>    Prompt: Broadcom STB NAND controller
>>      Location:
>>        -> Device Drivers
>>          -> Memory Technology Device (MTD) support (MTD [=y])
>>    (1)     -> NAND Device Support (MTD_NAND [=n])
>>      Defined at drivers/mtd/nand/Kconfig:394
>>      Depends on: MTD [=y] && MTD_NAND [=n] && (ARM [=y] || ARM64 || MIPS)
> 
> Sorry, can't reproduce it any more. My patch is dated June 4, so it was
> probably broken then but got fixed since. I normally try to verify that
> the patches are still needed before I send them, but this time I only
> saw the current discussion and remembered something vague about it
> and sent what I had in my backlog of the randconfig-fixes series.

It may have been a problem before this patch:

d80d942bcc8e1555a76774d20be9800cfef2d415 ("ARM: BCM: Do not select
CONFIG_MTD_NAND_BRCMNAND")
-- 
Florian

[PATCH v2 2/4] mtd: nand: Allow MTD_NAND_BRCMNAND to be selected for ARM64

[Arnd Bergmann]

On Friday 16 October 2015 12:28:03 Florian Fainelli wrote:
> > 
> > Sorry, can't reproduce it any more. My patch is dated June 4, so it was
> > probably broken then but got fixed since. I normally try to verify that
> > the patches are still needed before I send them, but this time I only
> > saw the current discussion and remembered something vague about it
> > and sent what I had in my backlog of the randconfig-fixes series.
> 
> It may have been a problem before this patch:
> 
> d80d942bcc8e1555a76774d20be9800cfef2d415 ("ARM: BCM: Do not select
> CONFIG_MTD_NAND_BRCMNAND")
> -- 
> 

Yes, that must have been it. So my patch was not only outdated but
also wrong ;-)

	Arnd

[PATCH v2 3/4] mtd: brcmnand: Force 8bit mode before doing nand_scan_ident()

[Anup Patel]

Just like other NAND controllers, the NAND READID command only works
in 8bit mode for all versions of BRCMNAND controller.

This patch forces 8bit mode for each NAND CS in brcmnand_init_cs()
before doing nand_scan_ident() to ensure that BRCMNAND controller
is in 8bit mode when NAND READID command is issued.

Signed-off-by: Anup Patel <anup.patel@broadcom.com>
Reviewed-by: Ray Jui <rjui@broadcom.com>
Reviewed-by: Scott Branden <sbranden@broadcom.com>
---
 drivers/mtd/nand/brcmnand/brcmnand.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c b/drivers/mtd/nand/brcmnand/brcmnand.c
index 4cba03d..0be8ef9 100644
--- a/drivers/mtd/nand/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/brcmnand/brcmnand.c
@@ -1888,6 +1888,7 @@ static int brcmnand_init_cs(struct brcmnand_host *host)
 	struct mtd_info *mtd;
 	struct nand_chip *chip;
 	int ret;
+	u16 cfg_offs;
 	struct mtd_part_parser_data ppdata = { .of_node = dn };
 
 	ret = of_property_read_u32(dn, "reg", &host->cs);
@@ -1930,6 +1931,14 @@ static int brcmnand_init_cs(struct brcmnand_host *host)
 
 	chip->controller = &ctrl->controller;
 
+	/*
+	 * The bootloader might have configured 16bit mode but
+	 * NAND READID command only works in 8bit mode. We force
+	 * 8bit mode here to ensure that NAND READID commands works.
+	 */
+	cfg_offs = brcmnand_cs_offset(ctrl, host->cs, BRCMNAND_CS_CFG);
+	nand_writereg(ctrl, cfg_offs, nand_readreg(ctrl, cfg_offs) & ~BIT(23));
+
 	if (nand_scan_ident(mtd, 1, NULL))
 		return -ENXIO;
 
-- 
1.9.1

[PATCH v2 4/4] arm64: dts: Add BRCM IPROC NAND DT node for NS2

[Anup Patel]

The NAND controller on NS2 SoC is compatible with existing
BRCM IPROC NAND driver so let's enable it in NS2 DT and
NS2 SVK DT.

Signed-off-by: Anup Patel <anup.patel@broadcom.com>
Reviewed-by: Ray Jui <rjui@broadcom.com>
Reviewed-by: Scott Branden <sbranden@broadcom.com>
---
 arch/arm64/boot/dts/broadcom/ns2-svk.dts | 12 ++++++++++++
 arch/arm64/boot/dts/broadcom/ns2.dtsi    | 14 ++++++++++++++
 2 files changed, 26 insertions(+)

diff --git a/arch/arm64/boot/dts/broadcom/ns2-svk.dts b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
index e5950d5..a754160 100644
--- a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
+++ b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
@@ -63,5 +63,17 @@
 		uart3: serial at 66130000 {
 			status = "ok";
 		};
+
+		nand: nand at 66460000 {
+			nandcs at 0 {
+				compatible = "brcm,nandcs";
+				reg = <0>;
+				nand-ecc-mode = "hw";
+				nand-ecc-strength = <8>;
+				nand-ecc-step-size = <512>;
+				#address-cells = <1>;
+				#size-cells = <1>;
+			};
+		};
 	};
 };
diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index f603277..9610822 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -212,5 +212,19 @@
 			compatible = "brcm,iproc-rng200";
 			reg = <0x66220000 0x28>;
 		};
+
+		nand: nand at 66460000 {
+			compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1";
+			reg = <0x66460000 0x600>,
+			      <0x67015408 0x600>,
+			      <0x66460f00 0x20>;
+			reg-names = "nand", "iproc-idm", "iproc-ext";
+			interrupts = <GIC_SPI 420 IRQ_TYPE_LEVEL_HIGH>;
+
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			brcm,nand-has-wp;
+		};
 	};
 };
-- 
1.9.1

[PATCH v2 4/4] arm64: dts: Add BRCM IPROC NAND DT node for NS2

[Sudeep Holla]

On 16/10/15 10:08, Anup Patel wrote:
> The NAND controller on NS2 SoC is compatible with existing
> BRCM IPROC NAND driver so let's enable it in NS2 DT and
> NS2 SVK DT.
>
> Signed-off-by: Anup Patel <anup.patel@broadcom.com>
> Reviewed-by: Ray Jui <rjui@broadcom.com>
> Reviewed-by: Scott Branden <sbranden@broadcom.com>
> ---
>   arch/arm64/boot/dts/broadcom/ns2-svk.dts | 12 ++++++++++++
>   arch/arm64/boot/dts/broadcom/ns2.dtsi    | 14 ++++++++++++++
>   2 files changed, 26 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/broadcom/ns2-svk.dts b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
> index e5950d5..a754160 100644
> --- a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
> +++ b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
> @@ -63,5 +63,17 @@
>   		uart3: serial at 66130000 {
>   			status = "ok";
>   		};

Better to change even the above reference, see below.

> +
> +		nand: nand at 66460000 {

In most of the cases where such static overlays are done, I have seen
the labels being used to refer back the node. Using the complete node
name again is kind of inviting trouble as even minor typo results in
creation of another node.

-- 
Regards,
Sudeep

[PATCH v2 4/4] arm64: dts: Add BRCM IPROC NAND DT node for NS2

[Anup Patel]

> -----Original Message-----
> From: Sudeep Holla [mailto:sudeep.holla at arm.com]
> Sent: 20 October 2015 14:36
> To: Anup Patel
> Cc: David Woodhouse; Brian Norris; linux-mtd at lists.infradead.org; Sudeep
> Holla; Rob Herring; Pawel Moll; Mark Rutland; Ian Campbell; Kumar Gala; Catalin
> Marinas; Will Deacon; Ray Jui; Scott Branden; Florian Fainelli; Pramod Kumar;
> Vikram Prakash; Sandeep Tripathy; linux-arm-kernel at lists.infradead.org;
> devicetree at vger.kernel.org; linux-kernel at vger.kernel.org; bcm-kernel-
> feedback-list
> Subject: Re: [PATCH v2 4/4] arm64: dts: Add BRCM IPROC NAND DT node for
> NS2
> 
> 
> 
> On 16/10/15 10:08, Anup Patel wrote:
> > The NAND controller on NS2 SoC is compatible with existing BRCM IPROC
> > NAND driver so let's enable it in NS2 DT and
> > NS2 SVK DT.
> >
> > Signed-off-by: Anup Patel <anup.patel@broadcom.com>
> > Reviewed-by: Ray Jui <rjui@broadcom.com>
> > Reviewed-by: Scott Branden <sbranden@broadcom.com>
> > ---
> >   arch/arm64/boot/dts/broadcom/ns2-svk.dts | 12 ++++++++++++
> >   arch/arm64/boot/dts/broadcom/ns2.dtsi    | 14 ++++++++++++++
> >   2 files changed, 26 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
> > b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
> > index e5950d5..a754160 100644
> > --- a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
> > +++ b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
> > @@ -63,5 +63,17 @@
> >   		uart3: serial at 66130000 {
> >   			status = "ok";
> >   		};
> 
> Better to change even the above reference, see below.
> 
> > +
> > +		nand: nand at 66460000 {
> 
> In most of the cases where such static overlays are done, I have seen the labels
> being used to refer back the node. Using the complete node name again is kind
> of inviting trouble as even minor typo results in creation of another node.

Thanks for pointing. I will use label here for both uart3 and nand.

Regards,
Anup