From: Mike Dunn <mikedunn@newsguy.com>
To: Brian Norris <computersforpeace@gmail.com>
Cc: David Woodhouse <dwmw2@infradead.org>,
linux-mtd@lists.infradead.org,
Shmulik Ladkani <shmulik.ladkani@gmail.com>,
Artem Bityutskiy <dedekind1@gmail.com>
Subject: Re: [PATCH 2/8] mtd: check for max_bitflips in mtd_read_oob()
Date: Tue, 26 Jun 2012 11:23:22 -0700 [thread overview]
Message-ID: <4FE9FE1A.9070801@newsguy.com> (raw)
In-Reply-To: <1340408145-24531-3-git-send-email-computersforpeace@gmail.com>
On 06/22/2012 04:35 PM, Brian Norris wrote:
> mtd_read_oob() has some unexpected similarities to mtd_read(). For
> instance, when ops->datbuf != NULL, nand_base.c might return max_bitflips;
> however, when ops->datbuf == NULL, nand_base's code potentially could
> return -EUCLEAN (no in-tree drivers do this yet). In any case where the
> driver might return max_bitflips, we should translate this into an
> appropriate return code using the bitflip_threshold.
>
> Essentially, mtd_read_oob() duplicates the logic from mtd_read().
>
> This prevents users of mtd_read_oob() from receiving a positive return
> value (i.e., from max_bitflips) and interpreting it as an unknown error.
Reviewed-by Mike Dunn <mikedunn@newsguy.com>
This should fix the problem, but it's still confusing and inconsistent; see below...
>
> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
> Cc: Shmulik Ladkani <shmulik.ladkani@gmail.com>
> Cc: Mike Dunn <mikedunn@newsguy.com>
> ---
> drivers/mtd/mtdcore.c | 14 +++++++++++++-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
> index fcfce24..75288d3 100644
> --- a/drivers/mtd/mtdcore.c
> +++ b/drivers/mtd/mtdcore.c
> @@ -860,10 +860,22 @@ EXPORT_SYMBOL_GPL(mtd_panic_write);
>
> int mtd_read_oob(struct mtd_info *mtd, loff_t from, struct mtd_oob_ops *ops)
> {
> + int ret_code;
> ops->retlen = ops->oobretlen = 0;
> if (!mtd->_read_oob)
> return -EOPNOTSUPP;
> - return mtd->_read_oob(mtd, from, ops);
> + /*
> + * In cases where ops->datbuf != NULL, mtd->_read_oob() can have
> + * semantics similar to mtd->_read(), regarding max bitflips. In other
> + * cases, mtd->_read_oob() may return -EUCLEAN. In all cases, perform
> + * similar logic to mtd_read() (see above).
> + */
> + ret_code = mtd->_read_oob(mtd, from, ops);
> + if (unlikely(ret_code < 0))
> + return ret_code;
As Brian explains in the comment, here the return code propagated up could be
-EUCLEAN for an oob-only read (ops->databuf == NULL), which is unlike the
mtd_read() case, where here only a hard error will be propagated up. To be
consistent, nand_do_read_oob(), and non-nand drivers' implementation of
mtd->_read_oob(), should not return -EUCLEAN. When (or if) a policy is decided
for reporting bitflips within the oob area, this will need to be revisited.
Thanks Brian!
> + if (mtd->ecc_strength == 0)
> + return 0; /* device lacks ecc */
> + return ret_code >= mtd->bitflip_threshold ? -EUCLEAN : 0;
> }
> EXPORT_SYMBOL_GPL(mtd_read_oob);
>
next prev parent reply other threads:[~2012-06-26 18:23 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-22 23:35 [PATCH 0/8] NAND and NAND-BBT improvements Brian Norris
2012-06-22 23:35 ` [PATCH 1/8] mtd: move mtd_read_oob() definition out of mtd.h Brian Norris
2012-06-22 23:35 ` [PATCH 2/8] mtd: check for max_bitflips in mtd_read_oob() Brian Norris
2012-06-26 12:11 ` Shmulik Ladkani
2012-06-26 18:23 ` Mike Dunn [this message]
2012-07-11 2:12 ` Brian Norris
2012-08-15 11:24 ` Artem Bityutskiy
2012-08-15 19:15 ` Brian Norris
2012-08-16 10:48 ` Artem Bityutskiy
2012-08-17 22:58 ` Brian Norris
2012-06-22 23:35 ` [PATCH 3/8] mtd: nand: rename "no_bbt" descriptors to "no_oob" Brian Norris
2012-06-22 23:35 ` [PATCH 4/8] mtd: nand: remove unused 'int' return codes Brian Norris
2012-06-26 12:29 ` Shmulik Ladkani
2012-06-26 14:18 ` [PATCH 4/8] mtd: nand: remove unused 'int' return codes (SPAM) William F.
2012-08-15 11:40 ` [PATCH 4/8] mtd: nand: remove unused 'int' return codes Artem Bityutskiy
2012-06-22 23:35 ` [PATCH 5/8] mtd: nand: rename '_raw' BBT scan functions Brian Norris
2012-06-26 12:39 ` Shmulik Ladkani
2012-07-10 2:13 ` Brian Norris
2012-08-15 12:35 ` Artem Bityutskiy
2012-06-22 23:35 ` [PATCH 6/8] mtd: nand_bbt: refactor check_pattern_no_oob() Brian Norris
2012-06-22 23:35 ` [PATCH 7/8] mtd: nand_bbt: use string library Brian Norris
2012-06-26 13:37 ` Shmulik Ladkani
2012-07-16 6:06 ` Brian Norris
2012-07-16 23:57 ` Ivan Djelic
2012-08-15 11:53 ` Artem Bityutskiy
2012-06-22 23:35 ` [PATCH 8/8] mtd: nand: use ECC, if present, when scanning OOB Brian Norris
2012-06-26 14:09 ` Shmulik Ladkani
2012-07-10 2:39 ` Brian Norris
2012-07-10 7:45 ` Matthieu CASTET
2012-07-13 17:39 ` Brian Norris
2012-07-15 20:01 ` Mike Dunn
2012-07-16 14:01 ` Ivan Djelic
2012-07-16 18:36 ` Mike Dunn
2012-07-16 21:34 ` Ivan Djelic
2012-07-17 18:10 ` Mike Dunn
2013-11-07 14:56 ` Angus Clark
2013-11-18 18:36 ` Brian Norris
2012-08-15 12:05 ` Artem Bityutskiy
2012-08-15 14:31 ` Shmulik Ladkani
2012-08-16 10:40 ` Artem Bityutskiy
2012-08-20 13:12 ` Shmulik Ladkani
2012-06-27 13:52 ` [PATCH 0/8] NAND and NAND-BBT improvements Artem Bityutskiy
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=4FE9FE1A.9070801@newsguy.com \
--to=mikedunn@newsguy.com \
--cc=computersforpeace@gmail.com \
--cc=dedekind1@gmail.com \
--cc=dwmw2@infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=shmulik.ladkani@gmail.com \
/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.