From: Brian Norris <computersforpeace@gmail.com>
To: <linux-mtd@lists.infradead.org>
Cc: Huang Shijie <b32955@freescale.com>,
Brian Norris <computersforpeace@gmail.com>,
Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Subject: [PATCH] mtd: nand: cleanup ONFI printed errors, warnings
Date: Wed, 11 Sep 2013 16:08:14 -0700 [thread overview]
Message-ID: <1378940894-27598-1-git-send-email-computersforpeace@gmail.com> (raw)
The ONFI detection routine is too verbose in some cases and not verbose
enough in others. This patch refactors it to print only when there are
significant warnings/errors.
Probing in 16-bit mode:
It is unnecessary to print until after the READID (address 20h)
command. READID *has* to work properly in whatever bus width
configuration we are in, or else no identification mode works. So we
can silence some useless warnings on systems which come up in 16-bit
mode and do not even respond with an O-N-F-I string.
Valid parameter page:
Nobody needs to see this. Do we inform the user every time other
hardware responds properly? Instead, add an error message if *no*
uncorrupted parameter pages are found.
ONFI ECC:
Most drivers don't yet use the reported minimum ECC values, so it
shouldn't yet be a fatal condition if the extended parameter page is
incorrect. But we should at least give a warning for the corner cases
that we don't expect.
ONFI flash detected:
Nobody needs to see this. This is the expected case, that we detect
ONFI properly, or else it wasn't ONFI-compliant and is detected by
some other routine.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Cc: Huang Shijie <b32955@freescale.com>
Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
drivers/mtd/nand/nand_base.c | 24 +++++++++++++++---------
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 7ed4841..d4578a1 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -2937,29 +2937,34 @@ static int nand_flash_detect_onfi(struct mtd_info *mtd, struct nand_chip *chip,
int i;
int val;
- /* ONFI need to be probed in 8 bits mode, and 16 bits should be selected with NAND_BUSWIDTH_AUTO */
- if (chip->options & NAND_BUSWIDTH_16) {
- pr_err("Trying ONFI probe in 16 bits mode, aborting !\n");
- return 0;
- }
/* Try ONFI for unknown chip or LP */
chip->cmdfunc(mtd, NAND_CMD_READID, 0x20, -1);
if (chip->read_byte(mtd) != 'O' || chip->read_byte(mtd) != 'N' ||
chip->read_byte(mtd) != 'F' || chip->read_byte(mtd) != 'I')
return 0;
+ /*
+ * ONFI must be probed in 8-bit mode or with NAND_BUSWIDTH_AUTO, not
+ * with NAND_BUSWIDTH_16
+ */
+ if (chip->options & NAND_BUSWIDTH_16) {
+ pr_err("ONFI cannot be probed in 16-bit mode; aborting\n");
+ return 0;
+ }
+
chip->cmdfunc(mtd, NAND_CMD_PARAM, 0, -1);
for (i = 0; i < 3; i++) {
chip->read_buf(mtd, (uint8_t *)p, sizeof(*p));
if (onfi_crc16(ONFI_CRC_BASE, (uint8_t *)p, 254) ==
le16_to_cpu(p->crc)) {
- pr_info("ONFI param page %d valid\n", i);
break;
}
}
- if (i == 3)
+ if (i == 3) {
+ pr_err("Could not find valid ONFI parameter page; aborting\n");
return 0;
+ }
/* Check version */
val = le16_to_cpu(p->revision);
@@ -3011,10 +3016,11 @@ static int nand_flash_detect_onfi(struct mtd_info *mtd, struct nand_chip *chip,
/* The Extended Parameter Page is supported since ONFI 2.1. */
if (nand_flash_detect_ext_param_page(mtd, chip, p))
- pr_info("Failed to detect the extended param page.\n");
+ pr_warn("Failed to detect ONFI extended param page\n");
+ } else {
+ pr_warn("Could not retrieve ONFI ECC requirements\n");
}
- pr_info("ONFI flash detected\n");
return 1;
}
--
1.8.4
next reply other threads:[~2013-09-11 23:09 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-11 23:08 Brian Norris [this message]
2013-09-12 12:24 ` [PATCH] mtd: nand: cleanup ONFI printed errors, warnings Ezequiel Garcia
2013-09-12 14:49 ` Ezequiel Garcia
2013-09-30 23:20 ` Brian Norris
2013-09-17 1:03 ` Brian Norris
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1378940894-27598-1-git-send-email-computersforpeace@gmail.com \
--to=computersforpeace@gmail.com \
--cc=b32955@freescale.com \
--cc=ezequiel.garcia@free-electrons.com \
--cc=linux-mtd@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.