diff mbox

[U-Boot,08/11] mtd: nand: honor CONFIG_SYS_NAND_QUIET_TEST with unknown NAND printk

Message ID 1283296887-8631-9-git-send-email-steve@sakoman.com
State Superseded
Headers show

Commit Message

Steve Sakoman Aug. 31, 2010, 11:21 p.m. UTC
This printk was added recently and results in ugly output on systems
with no NAND:

NAND:  nand_get_flash_type: unknown NAND device: Manufacturer ID: 0x00, Chip ID: 0x00 0 MiB

instead of:

NAND:  0 MiB

Signed-off-by: Steve Sakoman <steve@sakoman.com>
---
 drivers/mtd/nand/nand_base.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

Comments

Sandeep Paulraj Sept. 1, 2010, 12:18 a.m. UTC | #1
> 
> This printk was added recently and results in ugly output on systems
> with no NAND:
> 
> NAND:  nand_get_flash_type: unknown NAND device: Manufacturer ID: 0x00,
> Chip ID: 0x00 0 MiB
> 
> instead of:
> 
> NAND:  0 MiB

Scott,

What do you think of this patch?



> 
> Signed-off-by: Steve Sakoman <steve@sakoman.com>
> ---
>  drivers/mtd/nand/nand_base.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
> index ed1c9c9..cbcf2b8 100644
> --- a/drivers/mtd/nand/nand_base.c
> +++ b/drivers/mtd/nand/nand_base.c
> @@ -2653,9 +2653,11 @@ static struct nand_flash_dev
> *nand_get_flash_type(struct mtd_info *mtd,
>  	}
> 
>  	if (!type) {
> +#ifndef CONFIG_SYS_NAND_QUIET_TEST
>  		printk(KERN_INFO "%s: unknown NAND device: Manufacturer ID:"
>  		       " 0x%02x, Chip ID: 0x%02x\n", __func__,
>  		       *maf_id, dev_id);
> +#endif
>  		return ERR_PTR(-ENODEV);
>  	}
> 
> --
> 1.7.0.4
>
Scott Wood Sept. 1, 2010, 4:26 p.m. UTC | #2
On Tue, 31 Aug 2010 19:18:27 -0500
"Paulraj, Sandeep" <s-paulraj@ti.com> wrote:

> 
> 
> > 
> > This printk was added recently and results in ugly output on systems
> > with no NAND:
> > 
> > NAND:  nand_get_flash_type: unknown NAND device: Manufacturer ID: 0x00,
> > Chip ID: 0x00 0 MiB
> > 
> > instead of:
> > 
> > NAND:  0 MiB
[snip]
> >  	if (!type) {
> > +#ifndef CONFIG_SYS_NAND_QUIET_TEST
> >  		printk(KERN_INFO "%s: unknown NAND device: Manufacturer ID:"
> >  		       " 0x%02x, Chip ID: 0x%02x\n", __func__,
> >  		       *maf_id, dev_id);
> > +#endif
> >  		return ERR_PTR(-ENODEV);
> >  	}
> > 

Hmm, the current use of that seems to be suppressing warnings about
NAND that isn't present at all, not about NAND whose type we don't
recognize.

Perhaps we could instead suppress the warning only for probably-invalid
values such as 0x00 and 0xff, if that's how a missing NAND chip
manifests?

-Scott
Steve Sakoman Sept. 1, 2010, 4:43 p.m. UTC | #3
On Wed, 2010-09-01 at 11:26 -0500, Scott Wood wrote:
> On Tue, 31 Aug 2010 19:18:27 -0500
> "Paulraj, Sandeep" <s-paulraj@ti.com> wrote:
> 
> > 
> > 
> > > 
> > > This printk was added recently and results in ugly output on systems
> > > with no NAND:
> > > 
> > > NAND:  nand_get_flash_type: unknown NAND device: Manufacturer ID: 0x00,
> > > Chip ID: 0x00 0 MiB
> > > 
> > > instead of:
> > > 
> > > NAND:  0 MiB
> [snip]
> > >  	if (!type) {
> > > +#ifndef CONFIG_SYS_NAND_QUIET_TEST
> > >  		printk(KERN_INFO "%s: unknown NAND device: Manufacturer ID:"
> > >  		       " 0x%02x, Chip ID: 0x%02x\n", __func__,
> > >  		       *maf_id, dev_id);
> > > +#endif
> > >  		return ERR_PTR(-ENODEV);
> > >  	}
> > > 
> 
> Hmm, the current use of that seems to be suppressing warnings about
> NAND that isn't present at all, not about NAND whose type we don't
> recognize.

Well, that is precisely the case for new Beagle's and Overo's -- these
boards do not have nand and output this error.

So perhaps the real issue is that "no nand" is being reported as having
a manufacturer id of 0x00 and device id of 0x00 ?

> Perhaps we could instead suppress the warning only for probably-invalid
> values such as 0x00 and 0xff, if that's how a missing NAND chip
> manifests?

That would also be acceptable to me.  Is this your preferred fix?

Steve
Scott Wood Sept. 1, 2010, 5:55 p.m. UTC | #4
On Wed, 1 Sep 2010 09:43:17 -0700
Steve Sakoman <steve@sakoman.com> wrote:

> On Wed, 2010-09-01 at 11:26 -0500, Scott Wood wrote:
> > Hmm, the current use of that seems to be suppressing warnings about
> > NAND that isn't present at all, not about NAND whose type we don't
> > recognize.
> 
> Well, that is precisely the case for new Beagle's and Overo's -- these
> boards do not have nand and output this error.

Right, I just don't want to end up suppressing the message if there's a
real flash that just needs an ID table update.

> > Perhaps we could instead suppress the warning only for probably-invalid
> > values such as 0x00 and 0xff, if that's how a missing NAND chip
> > manifests?
> 
> That would also be acceptable to me.  Is this your preferred fix?

Yes.

-Scott
diff mbox

Patch

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index ed1c9c9..cbcf2b8 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -2653,9 +2653,11 @@  static struct nand_flash_dev *nand_get_flash_type(struct mtd_info *mtd,
 	}
 
 	if (!type) {
+#ifndef CONFIG_SYS_NAND_QUIET_TEST
 		printk(KERN_INFO "%s: unknown NAND device: Manufacturer ID:"
 		       " 0x%02x, Chip ID: 0x%02x\n", __func__,
 		       *maf_id, dev_id);
+#endif
 		return ERR_PTR(-ENODEV);
 	}